linux-kernel - Re: Too many I/O controller patches

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, 05 Aug 2008 09:20:18 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	righi.andrea@...il.com
Cc:	Satoshi UCHIDA <s-uchida@...jp.nec.com>,
	xen-devel@...ts.xensource.com,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, vtaras@...nvz.org,
	dm-devel@...hat.com, agk@...rceware.org,
	virtualization@...ts.linux-foundation.org, ngupta@...gle.com
Subject: Re: Too many I/O controller patches

On Tue, 2008-08-05 at 11:28 +0200, Andrea Righi wrote:
> > Buffered write I/O is also related with cache system.
> > We must consider this problem as I/O control.
> 
> Agree. At least, maybe we should consider if an IO controller could be
> a valid solution also for these problems.

Isn't this one of the core points that we keep going back and forth
over?  It seems like people are arguing in circles over this:

Do we:
	1. control potential memory usage by throttling I/O
or
	2. Throttle I/O when memory is full

I might lean toward (1) if we didn't already have a memory controller.
But, we have one, and it works.  Also, we *already* do (2) in the
kernel, so it would seem to graft well onto existing mechanisms that we
have.

I/O controllers should not worry about memory.  They're going to have a
hard enough time getting the I/O part right. :)

Or, am I over-simplifying this?

-- Dave

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