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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 2 Apr 2009 16:00:55 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	jeff@...zik.org, drees76@...il.com, j@...nau.net,
	lsorense@...lub.uwaterloo.ca, tytso@....edu, jesper@...gh.cc,
	linux-kernel@...r.kernel.org
Subject: Re: Linux 2.6.29



On Thu, 2 Apr 2009, Andrew Morton wrote:
> 
> The thing which has always worried me about trying to do smart
> drop-behind is the cost of getting it wrong - and sometimes it _will_
> get it wrong.
> 
> Someone out there will have an important application which linearly
> writes a 1G file and then reads it all back in again.  They will get
> really upset when their runtime doubles.

Yes. The good news is that it would be a pretty easy tunable to have a 
"how soon do we writeback and how soon would we drop". And I do suspect 
that _dropping_ should default to off (exactly because of the kind of 
situation you bring up). 

As mentioned, at least in my experience the VM is pretty good at dropping 
the right pages anyway. It's when they are dirty or locked that we end up 
stuttering (or when we do fsync). And "start background writeout earlier" 
improves that case regardless of drop-behind.

But at the same time it is also unquestionably true that the current 
behavior tends to maximize throughput performance. Delaying the writes as 
long as possible is almost always the right thing for througput. 

In my experience, at least on desktops, latency is a lot more important 
than throughput is. And I don't think anybody wants to start the writes 
_immediately_. 

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