linux-kernel - Re: [PATCH 0/2] pdflush fix and enhancement

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: <20081231024609.GQ496@one.firstfloor.org>
Date:	Wed, 31 Dec 2008 03:46:09 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	"Peter W. Morreale" <pmorreale@...ell.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] pdflush fix and enhancement

On Tue, Dec 30, 2008 at 06:56:29PM -0700, Peter W. Morreale wrote:
> The rational is simply because one-size may not fit all.  Currently
> there is minimalistic tuning wrt pdflush thread creation. 

Thanks. Please put this into the commit description for future
reference. 

Some comments below.

> Each pdflush thread arbitrarily decides to create another thread solely
> on the basis of all currently existing threads being busy for >= one
> second.  So this can result in NCPUS pdflush threads being created
> 'concurrently' should all existing threads wind up in the idle check at
> the same time (I have seen this).  Or it can result in a thread being

So perhaps a simple lock serializing creation of new pdflush threads
would avoid the problem?

> More to the point, on small systems with few file systems, what is the
> point of having 8 (the current max) threads competing with each other on
> a single disk?  Likewise, on a 64-way, or larger system with dozens of
> filesystems/disks, why wouldn't I want more background flushing?

That makes some sense, but perhaps it would be better to base the default
size on the number of underlying block devices then?

Ok one issue there is that there are lots of different types of 
block devices, e.g. a big raid array may look like a single disk.
Still I suspect defaults based on the block devices would do reasonably
well.

> 
> I actually think the question is: Why not allow the admin to control
> this?  Since it seems like this is a matter of policy based on machine
> configuration. 

The kernel should know the current machine config and most 
admins don't really want to do very fine grained configuration;
they expect the system to perform well out of the box. That is
why it is adventageous to try to come up with good auto tuning.

> And btw Andi, I should have cc'ed you on this, I know from the flush
> code that you were heavily involved.  I only cc'ed Peter Z. since his
> name was in pdflush.c.  My apologies.  

No problem, but I think you're confusing me with someone else :). I don't
remember ever hacking on this. Perhaps you thought of Andrew Morton
who did pdflush originally.

-Andi

-- 
ak@...ux.intel.com
--
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/