| |||||||||||||
Which I/O controller is the fairest of them all?Which I/O controller is the fairest of them all?Posted May 15, 2009 19:37 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)Parent article: Which I/O controller is the fairest of them all?
This array already has the means to identify the owner for any given page in the system. Or, at least, it will identify an owner; there's no real attempt to track multiple owners of shared pages. The blkio-cgroup patch adds some fields to this array to make it easy to identify which control group is associated with a given page. Given that, and given that block I/O requests include the address of the memory pages involved, it is not too hard to look up a control group to associate with each request. Modules like dm-ioband can then use this information to control the bandwidth used by all requests, not just those initiated directly from user space. It's not obvious why you'd want to ding the owner of a page for the I/O associated with writing it out, unless that task is also blocked waiting for more pages. It seems like whatever is currently causing memory pressure might also be a good candidate to bill for this I/O, and that task may not be the task that owns the page getting operated on in the case of VM traffic. For example, suppose I load $MEMHOG, and it allocates lots of pages pushing 20 or 30 small, well behaved apps to disk. Why should $MEMHOG be able to charge all this traffic it's triggering to those 20 or 30 small tasks, effectively getting more than its share of bandwidth through the back door?
(Log in to post comments)
Which I/O controller is the fairest of them all? Posted May 16, 2009 20:16 UTC (Sat) by giraffedata (subscriber, #1954) [Link] It's not obvious why you'd want to ding the owner of a page for the I/O associated with writing it out, unless that task is also blocked waiting for more pages. I agree. Allocating I/O simply doesn't work in Linux, where most of the I/O is actually done independently by the kernel, not directly by users. The kernel needs instead to allocate among users the user-visible resources that the disk I/O supports. Charge a user for writing to a file. For dirtying a page. For nonlocal memory/file references. You can suspend process execution when these things (in aggregate) go over budget and thereby speed up other processes. But if we want something small and simple, charging a disk write to the owner of the page does a pretty good approximation of this in some of the most important cases, because in those cases the owning task is blocked waiting for pages because what it's doing is continually writing to disk-backed files, through the cache.
|
|||||||||||||