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]
Message-Id: <1182332621.21117.49.camel@twins>
Date:	Wed, 20 Jun 2007 11:43:41 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, davej@...hat.com,
	tim.c.chen@...ux.intel.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org
Subject: Re: Change in default vm_dirty_ratio

On Wed, 2007-06-20 at 11:20 +0200, Jens Axboe wrote:
> On Wed, Jun 20 2007, Peter Zijlstra wrote:
> > On Wed, 2007-06-20 at 11:14 +0200, Jens Axboe wrote:
> > > On Wed, Jun 20 2007, Andrew Morton wrote:
> > > > Perhaps our queues are too long - if the VFS _does_ back off, it'll take
> > > > some time for that to have an effect.
> > > > 
> > > > Perhaps the fact that the queue size knows nothing about the _size_ of the
> > > > requests in the queue is a problem.
> > > 
> > > It's complicated, the size may not matter a lot. 128 sequential 512kb IO
> > > may complete faster than 128 random 4kb IO's.
> > 
> > Yes, is there any way a queue could be limited to a certain amount of
> > 'completion time' ?
> 
> Not easily, we'd need some sort of disk profile for that to be remotely
> reliable.

Yes, I see the problem, benching the device is hard; you don't want it
to do it each time, nor for it to take too long. Also, write performance
might be destructive, also not quite wanted :-/

/me sees this libtune doom on the horizon again.

Something adaptive would be best, something that inserts barriers and
measures the time to complete and then solves the read speed, write
speed and seek latency. All during normal operation.

That would entail storing a bunch of these sample points, solve the
equation for sets of 3, and (time-) average the results.. ugh



-
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