wierd new config options

wierd new config options

[Christoph Hellwig]

Why is UNEVICTABLE_LRU and option?  Is there any rason to turn it off or
is this just to confuse users?

CORE_DUMP_DEFAULT_ELF_HEADERS is similarly odd, it turns something on
that break old userspace, this really really should be a sysctl to turn
on instead of a config option.

Re: wierd new config options

[Lee Schermerhorn]

On Thu, 2008-10-23 at 20:18 +0200, Christoph Hellwig wrote:
> Why is UNEVICTABLE_LRU and option?  Is there any rason to turn it off or
> is this just to confuse users?


We discussed this back when we first submitted the patches.  I
considered the NONRECLAIMABLE/UNEVICTABLE LRU mechanism to be a wee bit
experimental at the time.  I wasn't sure that all platform that do want
memory management would necessarily also want the unevictable lru.  It's
easier for me to build it with the option and remove it later than vice
versa.  If the consensus of the community is that it should always be
enabled, then I'm fine with removing the option.  

Lee

> 
> CORE_DUMP_DEFAULT_ELF_HEADERS is similarly odd, it turns something on
> that break old userspace, this really really should be a sysctl to turn
> on instead of a config option.

Re: wierd new config options

[Alexey Dobriyan]

On Thu, Oct 23, 2008 at 03:16:44PM -0400, Lee Schermerhorn wrote:
> On Thu, 2008-10-23 at 20:18 +0200, Christoph Hellwig wrote:
> > Why is UNEVICTABLE_LRU and option?  Is there any rason to turn it off or
> > is this just to confuse users?
> 
> 
> We discussed this back when we first submitted the patches.  I
> considered the NONRECLAIMABLE/UNEVICTABLE LRU mechanism to be a wee bit
> experimental at the time.  I wasn't sure that all platform that do want
> memory management would necessarily also want the unevictable lru.  It's
> easier for me to build it with the option and remove it later than vice
> versa.  If the consensus of the community is that it should always be
> enabled, then I'm fine with removing the option.  

The problem is that average admin can't make useful judgement on
this: active pageout lists -- what the hell is it?, kswapd -- ok, I
remember this process from ps(1) output, "will not waste" -- ok, good
thing, "will use one page flag" -- how many more I have?, what will
happen if they emptied?

And distro kernel maintainer should also make a decision -- not a module, after all.

Re: wierd new config options

[Rik van Riel]

Christoph Hellwig wrote:
> Why is UNEVICTABLE_LRU and option?  Is there any rason to turn it off or
> is this just to confuse users?

Since the swapout code itself is already configurable with
CONFIG_SWAP, I do believe we want to be able to config out
the unevictable LRU code.

I guess it could be argued that maybe CONFIG_UNEVICTABLE_LRU
should just be folded into CONFIG_SWAP...

-- 
All Rights Reversed

Re: wierd new config options

[Christoph Hellwig]

On Thu, Oct 23, 2008 at 03:59:42PM -0400, Rik van Riel wrote:
> Christoph Hellwig wrote:
> >Why is UNEVICTABLE_LRU and option?  Is there any rason to turn it off or
> >is this just to confuse users?
> 
> Since the swapout code itself is already configurable with
> CONFIG_SWAP, I do believe we want to be able to config out
> the unevictable LRU code.
> 
> I guess it could be argued that maybe CONFIG_UNEVICTABLE_LRU
> should just be folded into CONFIG_SWAP...

Sounds like a good plan.

Re: wierd new config options

[Roland McGrath]

> CORE_DUMP_DEFAULT_ELF_HEADERS is similarly odd, it turns something on
> that break old userspace, this really really should be a sysctl to turn
> on instead of a config option.

Both the kconfig help text and the commit's log mention that this is
controlled per-process via /proc/PID/coredump_filter.  The new config
option only changes the boot-time default value to be inherited.


Thanks,
Roland