linux-kernel - Re: Approaches to making io

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: <m2pqjlo6e5.fsf@firstfloor.org>
Date:	Wed, 31 Aug 2011 10:08:50 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Daniel Ehrenberg <dehrenberg@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Approaches to making io_submit not block

Christoph Hellwig <hch@...radead.org> writes:
>
> I'll get it polished up and send it out for RFC once Dave sends out
> the updated allocation workqueue patch.  With this he moves all
> allocator calls in XFS into a workqueue.  My direct I/O patch uses that
> fact to use that workqueue for the allocator call

Is that really a good direction? The problem when you push operations
from multiple threads all into a single resource (per cpu workqueue)
is that the CPU scheduler loses control over that because they
are all mixed up.

So if one guy submits a lot and another very little the "a lot" guy
can overwhelm the queue for the very little guy.

We also have similar problems with the IO schedulers, which also
rely on process context to make fairness decisions. If you remove
the process context they do badly.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/