Re: [PATCH 2.6.9-rc2-mm1 0/2] mm: memory policy for page cache allocation

[Ray Bryant]

William Lee Irwin III wrote:
> On Mon, Sep 20, 2004 at 08:30:12PM -0500, Ray Bryant wrote:
>
> > > I'm sorry if this is confusing, personal terminology usually gets in the 
> > > way.
> > > The idea is that just like for the page allocation policy (your current 
> > > code), if you wanted, you would have a global, default page cache 
> On Tue, Sep 21, 2004 at 11:13:54AM +0200, Andi Kleen wrote:
>
> > Having both a per process page cache and a global page cache policy
> > would seem like overkill to me.
> > And having both doesn't make much sense anyways, because when the 
> > system admin wants to change the global policy to free memory
> > on nodes he would still need to worry about conflicting per process policies 
> > anyways. So as soon as you have process policy you cannot easily
> > change global anymore.

(Andi,)

I don't think the requirement is so much to be able to dynamically change
policies while the system is running, I think that the requirement is to be
able to set the global policy at boot time or near then.  We don't want to
have to recompile the kernel to boot it for a webserver or fileserver (likely 
local page cache allocation) versus an HPC system (likely round robin
page cache allocation policy).

The rationale for the local policy is partially implementation (see below),
and thinking that even on your big HPC system, some processes in some cpusets
might be running a file server application, and they would want local
allocation.  Having said that, of course, begs the question as to whether we
need a per cpuset policy, I suppose.  But read on for the implemenation
argument, and if that is not persuasive, then I'll go with a global only
policy and see where that leads.

> Ray, would being able to change the default policy via kernel command-
> line options (and perhaps sysctl) suffice? It seems that a global
> default and some global state (e.g. per-cpu state) should largely
> capture what you're after. If not, could you clarify where it doesn't?

Bill,

That would capture most of our requirements, I think.  Part of the reason
for doing a global and local policy is that is the way that the code works 
now, and all I did was piggyback on that.  So, because there is a global
policy with a per process override for the existing page allocation policy,
you get a similiar structure for the page cache policy.

The overhead is an additional word per task structure, an additional
mempolicy copy (if there is a per process page cache allocation policy)
and structure, plus some code that looks like this in alloc_pages_by_policy():

struct page *
alloc_pages_by_policy(unsigned gfp, unsigned order, unsigned policy)
 {

       struct mempolicy *pol;

       if (policy >= NR_MEM_POLICIES)
               BUG();
       pol = current->mempolicy[policy];
       if (!pol)
               pol = default_policy[policy];
. . .

Som it is elegant that way and readily allows for additional memory
allocation cases (slab cache, anyone?).

> Also, this switch statement stuff is getting a little hairy; maybe
> it's time to bring in mempolicy_ops. Or at least trudging through the
> switch () statements is turning into a moderate amount of work for me.
>
>
> -- wli

Yes, it is getting a little out of hand.  However, if we can get by without
the MEMPOL_ROUNDROBIN, we are back to where we were there.

--
Best Regards,
Ray
-----------------------------------------------
                  Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@xxxxxxx             raybry@xxxxxxxxxxxxx
The box said: "Requires Windows 98 or better",
           so I installed Linux.
-----------------------------------------------

-
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/