lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 23 Aug 2010 14:42:48 +1000
From:	Neil Brown <neilb@...e.de>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, riel@...hat.com, david@...morbit.com,
	hch@....de, axboe@...nel.dk
Subject: Re: [PATCH] writeback: remove the internal 5% low bound on
 dirty_ratio

On Fri, 20 Aug 2010 15:50:54 +1000
Con Kolivas <kernel@...ivas.org> wrote:

> On Fri, 20 Aug 2010 02:13:25 pm KOSAKI Motohiro wrote:
> > > The dirty_ratio was silently limited to >= 5%. This is not a user
> > > expected behavior. Let's rip it.
> > >
> > > It's not likely the user space will depend on the old behavior.
> > > So the risk of breaking user space is very low.
> > >
> > > CC: Jan Kara <jack@...e.cz>
> > > CC: Neil Brown <neilb@...e.de>
> > > Signed-off-by: Wu Fengguang <fengguang.wu@...el.com>
> >
> > Thank you.
> > 	Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> 
> I have tried to do this in the past, and setting this value to 0 on some 
> machines caused the machine to come to a complete standstill with small 
> writes to disk. It seemed there was some kind of "minimum" amount of data 
> required by the VM before anything would make it to the disk and I never 
> quite found out where that blockade occurred. This was some time ago (3 years 
> ago) so I'm not sure if the problem has since been fixed in the VM since 
> then. I suggest you do some testing with this value set to zero before 
> approving this change.
> 

 If it is appropriate to have a lower limit, that should be imposed where
 the sysctl is defined in kernel/sysctl.c, not imposed after the fact where
 the value is used.

 As we now have dirty_bytes which over-rides dirty_ratio, there is little
 cost in having a lower_limit for dirty_ratio - it could even stay at 5% -
 but it really shouldn't be silent.  Writing a number below the limit to the
 sysctl file should fail.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ