Hello, > Hi both, > > Fernando is off this week, so may not be able to reply soon, sorry. > > Vivek Goyal wrote: > > On Fri, Sep 05, 2008 at 09:00:17PM +0900, Hirokazu Takahashi wrote: > >> Hi, fernando, > >> > >>>> IMHO, optimizing the synchronous path alone would justify the addition > >>>> of io_context in bio. There is more to this though. > >>>> > >>>> As you point out, it would seem that aio and buffered IO would not > >>>> benefit from caching the io context in the bio itself, but there are > >>>> some subtleties here. Let's consider stacking devices and buffered IO, > >>>> for example. When a bio enters such a device it may get replicated > >>>> several times and, depending on the topology, some other derivative bios > >>>> will be created (RAID1 and parity configurations come to mind, > >>>> respectively). The problem here is that the memory allocated for the > >>>> newly created bios will be owned by the corresponding dm or md kernel > >>>> thread, not the originator of the bio we are replicating or calculating > >>>> the parity bits from. > >>> I've already tried implementing this feature. Will you take a look > >>> at the thread whose subject is "I/O context inheritance" in > >>> http://www.uwsg.iu.edu/hypermail/linux/kernel/0804.2/index.html#2857. > >> When I started to implement this, I would make each bio have two > >> io_contexts -- per-process io_context which had ionice and > >> and per-cgroup io_context. > >> > > I am also trying to make bios have pointers to io_contexts and I have a > question concerning this, very simple one. > > Is it OK to think bio->bi_io_context is a cache to find the io_context > of an appropriate task, an issuer of this bio, which may sometimes not be > the direct one, e.g. stacking devices case. > > If so, is it same if we make bios have pointers to the issuers, tasks or > cgroups, of them and then find the io_contexts through these? No, I don't think it is always possible. The issuers may not exist when an io-scheduler or other modules start to handle the I/O requests. I know you can make linux kernel preserve all the context of the issuers until all the I/O requests belonging to them have finished, but it may lead waste of resources. I think this is the reason why io_context was introduced. > I sometimes tempted to say "this bio's io_context." > > > > > Hi Hirokazu, > > > > I had a question. Why are we trying to create another io_context or why > > are we trying to mix up existing io_context (which is per task or per > > thread group) with cgroups? > > > > To me we just need to know the "cgroup id" to take a specific action with > > a bio. We don't need whole io_context strucutre. So can't we just use > > something like, page->page_cgroup->bio_cgroup->cgrou_id or something like > > that. > > > > What I mean is that the only thing which we seem to require to differentiate > > between various bio is cgroup id it belongs to and that can be a single > > "unsigned long" stored at appropriate place. Why are we looking at > > creating a full io_context structure and trying to share it among all the > > members of a cgroup? > > > > > Thanks > > Vivek > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
