On Tue, May 14, 2013 at 04:24:42PM +0200, Oleg Nesterov wrote: > On 05/14, Oleg Nesterov wrote: > > > > I must admit, I do not understand what this code actually does ;) > > I didn't try to read it carefully though, but perhaps at least the > > changelog could explain more? > > OK, this is clear... > > But perhaps the changelog could explain who needs the "fast" version > of, say, find_next_zero_bit + test_and_set_bit ;) Just curious. Originally I wrote it for a driver (which still isn't open source) - but find_next_zero_bit()/test_and_set_bit() is exactly what it was using before and the performance gain was significant :) The reason I'm posting it now is because AIO currently uses a linked list for tracking outstanding kiocbs - for cancellation - and that linked list needs to be replaced; I'm implementing cancellation for regular direct IO and the linked list is a performance issue. All we need for cancellation is a way to iterate over all the (potentially) allocated kiocbs - it's really exactly the same problem as managing tags in the drivers I was working on before (they also need to be able to time out tags which is exactly the same as AIO cancellation). What I found really annoying about the problem is that the existing slab allocator tracks exactly what we need... but it's not exposed (and honestly probably shouldn't be). So, there were two choices: * hack up slab/slob/slub - fuck no * reuse my tag allocator, allocate kiocbs out of an array of pages. Also allocate the pages lazily so we don't regress on memory overhead. So, that's what I did. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
