Re: Curious about corner case in btrfs code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
>>> 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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux