lkml.org 
[lkml]   [2005]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] per thread page reservation patch
    Vladimir Saveliev wrote:
    > [...]
    > + if (order == 0) {
    > + page = perthread_pages_alloc();
    > + if (page != NULL)
    > + return page;
    > + }

    I hope this has not been extensively discussed yet, and I missed the
    thread but, does everybody think this is a good thing?

    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?

    At the very least this test should be moved to the very beginning of the
    function. It is of no use to calculate "can_try_harder" before running
    this code if it will use a reserved page.

    Having a specialized function to get the reserved pages, would also make
    the logic in "perthread_pages_reserve" more clear (i.e., that comment
    would become unnecessary), and lose the test to "in_interrupt()" in
    "perthread_pages_alloc", if I'm reading this correctly.

    --
    Paulo Marques - www.grupopie.com

    "A journey of a thousand miles begins with a single step."
    Lao-tzu, The Way of Lao-tzu
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:4.107 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site