Curious about corner case in btrfs code

[Mandeep Sandhu]

Then setup a test system which will reproduce hitting this corner case
and instrument your code to see is there's any gain at all.



On Tue, Aug 26, 2014 at 4:14 PM, Nick <xerofoify at gmail.com> wrote:
>
>
> On 08/26/2014 06:58 PM, Mandeep Sandhu wrote:
>> If it's a corner case, it won't be hit often enough right? And if it
>> was hit often enough, it wouldn't be corner case!? :)
>>
>> These 2 are mutually exclusive!
>>
>>
>> On Tue, Aug 26, 2014 at 3:47 PM, Nick <xerofoify at gmail.com> wrote:
>>> After reading through the code in inode.c today , I am curious about the comment and the following code I will paste
>>> below. I am curious if this corner case is hit often enough for me to write a patch to improve the speed of this
>>> corner case. Furthermore , compress_file_range is the function name, in case you can't guess by the pasted code.
>>> Regards Nick
>>> 411     /*
>>> 412      * we don't want to send crud past the end of i_size through
>>> 413      * compression, that's just a waste of CPU time.  So, if the
>>> 414      * end of the file is before the start of our current
>>> 415      * requested range of bytes, we bail out to the uncompressed
>>> 416      * cleanup code that can deal with all of this.
>>> 417      *
>>> 418      * It isn't really the fastest way to fix things, but this is a
>>> 419      * very uncommon corner.
>>> 420      */
>>> 421     if (actual_end <= start)
>>> 422             goto cleanup_and_bail_uncompressed;
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> I get that my question is if this corner case is hit, enough for me to write a patch to optimize it.
> In addition the comment states it isn't but want to known for standard compression workloads in btrfs
> if it's hit enough for me to work on this and how much speed degradation are me we doing my not writing
> it better.
> Nick