lkml.org 
[lkml]   [2020]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
    > On Thu 13-08-20 19:09:29, Thomas Gleixner wrote:
    > > Michal Hocko <mhocko@suse.com> writes:
    > [...]
    > > > Why should we limit the functionality of the allocator for something
    > > > that is not a real problem?
    > >
    > > We'd limit the allocator for exactly ONE new user which was aware of
    > > this problem _before_ the code hit mainline. And that ONE user is
    > > prepared to handle the fail.
    >
    > If we are to limit the functionality to this one particular user then
    > I would consider a dedicated gfp flag a huge overkill. It would be much
    > more easier to have a preallocated pool of pages and use those and
    > completely avoid the core allocator. That would certainly only shift the
    > complexity to the caller but if it is expected there would be only that
    > single user then it would be probably better than opening a can of worms
    > like allocator usable from raw spin locks.
    >
    Vlastimil raised same question earlier, i answered, but let me answer again:

    It is hard to achieve because the logic does not stick to certain static test
    case, i.e. it depends on how heavily kfree_rcu(single/double) are used. Based
    on that, "how heavily" - number of pages are formed, until the drain/reclaimer
    thread frees them.

    Preloading pages and keeping them for internal use, IMHO, seems not optimal
    from the point of resources wasting. It is better to have a fast mechanism to
    request a page and release it back for needs of others. As described about
    we do not know how much we will need.

    --
    Vlad Rezki

    \
     
     \ /
      Last update: 2020-08-14 14:17    [W:6.422 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site