linux-kernel - Re: merging the per-bdi writeback patchset

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]

Message-Id: <20090623204119.2245.A69D9226@jp.fujitsu.com>
Date:	Tue, 23 Jun 2009 20:44:16 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	kosaki.motohiro@...fujitsu.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>, hch@...radead.org
Subject: Re: merging the per-bdi writeback patchset

> > > > Can you please make reproduce program and post mesurement result?
> > > > I hope to mesure the same program on my box.
> > > 
> > > For which issue? Lumpy writeout can often be observed just by doing
> > > buffered writes to a bunch of files.
> > 
> > Yes, I know current behavior is not perfectly optimal.
> > but I haven't seen it cause serious issue.
> > 
> > Then, I guess you have big degression workload, yes? if so, I hope to
> > see it.
> 
> Not really, I was just interested in making it more optimal. I work from
> various fio job files, one case that is sped up greatly is doing random
> writes with mmap to an otherwise buffered file. pdflush is both lumpy
> and a lot slower there, even with many pdflush threads active. Looking
> at disk utilization, pdflush doesn't manage more than ~80% for that. The
> per-bdi writeback is completely smooth and gets about as close to 100%
> utilization as possible (around ~98% there). And this is just one 1
> disk, the per-bdi writeback scales nicely upwards. pdflush falls flat.
> 
> And then there are lots of cases where the performance is the same. For
> many workloads, pdflush isn't really very active.
> 
> > > > Plus, Can you please write more vervose patch description? your patch is a
> > > > bit harder review.
> > > 
> > > OK, I can probably improve on that. Do you mean the general description
> > > of the patchset, or some of the individual patches?
> > 
> > Hopefully both. honestly I haven't understand your main worryed issue.
> 
> Does the above help? It's all about making the writeback more
> consistent. So getting rid of the lumpy writeback and eliminating the
> pdflush starvation were the prime motivators.

ok, thanks.
I try to review your patch series without any bias later.



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