Re: [RFC] per thread page reservation patch

[Nikita Danilov]

Paulo Marques <pmarques@xxxxxxxxxxxx> writes:

[...]

>
> This seems like a very asymmetrical behavior. If the code explicitly
> reserves pages, it should explicitly use them, or it will become
> impossible to track down who is using what (not to mention that this
> will slow down every regular user of __alloc_pages, even if it is just
> for a quick test).
>
> Why are there specialized functions to reserve the pages, but then they
> are used through the standard __alloc_pages interface?

That's the whole idea behind this patch: at the beginning of "atomic"
operation, some number of pages is reserved. As these pages are
available through page allocator, _all_ allocations done by atomic
operation will use reserved pages transparently. For example:

        perthread_pages_reserve(nr, GFP_KERNEL);

        foo()->

            bar()->

                page = find_or_create_page(some_mapping, ...);

        perthread_pages_release(unused_pages);

find_or_create() pages will use pages reserved for this thread and,
hence, is guaranteed to succeed (given correct reservation).

Alternative is to pass some sort of handle all the way down to actual
calls to allocator, and to modify all generic code to use reservations.

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/