Re: [PATCH 01/02] cpuset memory spread slab cache filesys

[Paul Jackson]

> > No - having a single cpuset is the fastest path.  All tasks
> > are in that root cpuset in that case, and all nodes allowed.
> 
> Faster than no cpuset?

If CONFIG_CPUSET is enabled (which I thought was likely to become the
norm for most distros -- though you would know better than I if this is
likely) then:

	There is no such case as "no cpuset" !!

The minimal, fastest, case is one root cpuset holding all tasks.


> If something is a good default it shouldn't need user space
> configuration at all imho. Only the "weird" cases should.

So are you just saying we got the default backwards?

Well ... I left the default for memory spreading these
inode slab caches as it was - not spread (preferring
node local).

I did that because I did not have the awareness that this default
should be changed for most systems.  I tend to leave defaults as they
are, unless I have good reason to change them.

But for the SGI systems I care about, I'd prefer the default to be
spreading them.

If you think it would be better to change this default, now that the
mechanism is in place to do support spreading these slabs, then I could
certainly go along with that.

Then your systems would not have to do anything in user space, unless
they wanted to disable spreading these slabs (which of course they
could easily do using cpusets ;).

    Should we change the default to enable this spreading?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@xxxxxxx> 1.925.600.0401
-
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/