linux-kernel - Re: Change in default vm_dirty

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:	Tue, 19 Jun 2007 15:33:15 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	torvalds@...ux-foundation.org
Cc:	john@...ffel.org, akpm@...ux-foundation.org,
	tim.c.chen@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: Change in default vm_dirty_ratio

From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Tue, 19 Jun 2007 12:04:33 -0700 (PDT)

> 
> 
> On Tue, 19 Jun 2007, John Stoffel wrote:
> > 
> > Shouldn't the vm_dirty_ratio be based on the speed of the device, and
> > not the size of memory?
> 
> Yes. It should depend on:
>  - speed of the device(s) in question
>  - seekiness of the workload
>  - wishes of the user as per the latency of other operations.
> 
> However, nobody has ever found the required algorithm.
> 
> So "at most 10% of memory dirty" is a simple (and fairly _good_) 
> heuristic. Nobody has actually ever ended up complaining about the change 
> from 40% -> 10%, and as far as I know this was the first report (and it's 
> not so much because the change was bad, but because it showed up on a 
> benchmark - and I don't think that actually says anythign about anything 
> else then the behaviour of the benchmark itself)

I complained very early on that it makes my workstation basically just
hang doing disk writes when I do big git tree operations on my sparc64
workstation.

Restoring the old values makes that go away.

It's an arbitrary number because the correct setting is dependant
upon what you're doing and how fast your disks are.

So I really think the "only benchmarks like the old settings"
argument doesn't really apply.

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