On 08/26/2014 08:05 PM, Tobias Boege wrote: > On Tue, 26 Aug 2014, Nick 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 >> > > Here's how I would go about it: > > 1. Understand when the case is met (in theory). > 2. Try to trigger it on a real system multiple times. > 3. Try to explore systematically under what circumstances the case is met > and rank them by plausibility (if the notion of plausibility makes any > sense in a real world scenario -- I don't know). > 4. Estimate cost vs. benefit. > > I don't know if this is a good way but notice how you can do all this on > yourself which I think is a plus for everyone. And if you decide in step 4 > to write a patch: > > 5. Use your results from step 3 to create an environment that benefits > from your patch (notice how 4 guarantees that there exists such a > system with reasonable connection to real needs). Note the numbers. > 6. Test your patch on as many regular configurations as possible. Note > the numbers. If it degrades performance on any of those, abort. > 7. Do *NOT* send the patch out. > > Regards, > Tobi > Thanks Tobi, >From reading the code off the bat, seems to not need to be written as this case is rarely meet for large files or files that are huge and take a lot of time to write. Was more curious about how to test things like this if I need to :). Nick _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
