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
| ||
|
Date: Wed, 6 Aug 2008 11:44:25 +0900 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> To: Dave Hansen <dave@...ux.vnet.ibm.com> Cc: righi.andrea@...il.com, 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, 05 Aug 2008 09:20:18 -0700 Dave Hansen <dave@...ux.vnet.ibm.com> wrote: > 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. I agree here ;) >They're going to have a hard enough time getting the I/O part right. :) > memcg have more problems now ;( Only a difficult thing to limit dirty-ratio in memcg is how-to-count dirty pages. If I/O controller's hook helps, it's good. My small concern is "What happens if we throttole I/O bandwidth too small under some memcg." In such cgroup, we may see more OOMs because I/O will not finish in time. A system admin have to find some way to avoid this. But please do I/O control first. Dirty-page control is related but different layer's problem, I think. Thanks, -Kame > Or, am I over-simplifying this? > -- 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