Re: [PATCH 3/4] Btrfs: handle unaligned tail of data ranges more efficient

2017-10-17 Thread David Sterba
On Mon, Oct 16, 2017 at 01:09:04AM +0300, Timofey Titovets wrote: > May be then just add a comment at least at one of that functions? > Like: > /* > * Handle unaligned end, end is inclusive, so always unaligned > */ This would be best documented in the data structure definition, so we don't

Re: [PATCH 3/4] Btrfs: handle unaligned tail of data ranges more efficient

2017-10-15 Thread Timofey Titovets
May be then just add a comment at least at one of that functions? Like: /* * Handle unaligned end, end is inclusive, so always unaligned */ Or something like: /* * It's obvious, kernel use paging, so range * Almost always have aligned start like 0 * and unaligned end like 8192 - 1 */ Or we

Re: [PATCH 3/4] Btrfs: handle unaligned tail of data ranges more efficient

2017-10-10 Thread David Sterba
On Tue, Oct 03, 2017 at 06:06:03PM +0300, Timofey Titovets wrote: > At now while switch page bits in data ranges > we always hande +1 page, for cover case > where end of data range is not page aligned The 'end' is inclusive and thus not aligned in most cases, ie. it's offset 4095 in the page, so

[PATCH 3/4] Btrfs: handle unaligned tail of data ranges more efficient

2017-10-03 Thread Timofey Titovets
At now while switch page bits in data ranges we always hande +1 page, for cover case where end of data range is not page aligned Let's handle that case more obvious and efficient Check end aligment directly and touch +1 page only then needed Signed-off-by: Timofey Titovets