From: Ross S. W. W. <rw...@me...> - 2007-05-30 20:14:30
|
> -----Original Message----- > From: isc...@li... > [mailto:isc...@li...] On > Behalf Of Ross S. W. Walker > Sent: Wednesday, May 30, 2007 3:45 PM > To: bla...@gm... > Cc: FUJITA Tomonori; isc...@li...; > mic...@cs... > Subject: Re: [Iscsitarget-devel] Help with regression in > linux-2.6.22-rcx > > > -----Original Message----- > > From: Ming Zhang [mailto:bla...@gm...] > > Sent: Wednesday, May 30, 2007 3:21 PM > > To: Ross S. W. Walker > > Cc: Boaz Harrosh; FUJITA Tomonori; > > isc...@li...; mic...@cs... > > Subject: RE: [Iscsitarget-devel] Help with regression in > > linux-2.6.22-rcx > > > > On Wed, 2007-05-30 at 15:15 -0400, Ross S. W. Walker wrote: <snip> > > > We could look at the feasibility of adding a VM throttle > > feature to IET > > > code though to take a more pro-active approach then relying > > on the kernel > > > to always do-the-right-thing. > > > > ;) for fileio with wb, iet writes into page cache and lose > > control after > > that stage! > > > > we can preserve some tio, buffer we use and avoid to allocate memory > > when system is under pressure, but other than those, what > else we can > > control? > > > > such control should always done in VM manager i believe. like > > you said, > > VM Manager should be able to control max page cache per system, per > > process. > > > > > > or another more proactive way is to do IET own cache and bypass page > > cache. can we do better than page cache? > > I believe there are advisory functions out there to give VM > manager hints > on how to handle excess VM baggage. > > We could advise out memory on a cache sync and advise out oldest > memory > device's read-ahead size and maybe that will help > keep VM usage > down. At least help. > > I think we can create a built-in cache if we put the effort > in. Page-cache > was initially designed to cache file system structures and > since we deal > with sectors and not files we can probably benefit from a > simpler cache > (not that the algo will be simpler, but the radix tree would > be, we can > just blantly copy the basic algo from page-cache). > > At that point there would be no need for file-io iotype, we can add > cache to block-io and get benefits of both worlds. Large > request handling > and caching. User can specify the size of read cache and/or > write cache > as part of the LUN parameters (I still think software write-cache is > evil though, but I like read caching). > > Having caching done in-process will most likely require a > separate thread > to manage the cache between worker threads, update read-ahead > plan, flush > dirty sectors out, issue read-aheads to cache, etc. > > Food for thought. Now that I thought about it a bit I think instead of trying to implement directly in existing code, if the caching mechanism can be implemented as a separate kernel module that acts as a generic block caching mechanism where volumes can be added to it from within code. The whole module can be told to reserve X RAM as a static cache and then to dedicate portions of it to volumes under it's control. Also if volumes are part of the same physical device they can utilize a unified read-ahead cache... This way the cache development process can progress without having to change how the existing IET works (besides the initial hooks to use the cache mechanism if it exists). -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. |