On Thu, 2003-02-27 at 22:49, Adrian Chadd wrote: > On Thu, Feb 27, 2003, Robert Collins wrote: > > > > What do people think? > > > > I'm working on a more generic solution at the moment, consolidating > > deferred reads and delay pools etc...... > > > > Rough notes in bugzilla, or pop onto IRC and we can discuss... > > Can I have a look at what you've done?
Sure. I'm pushing the arch mirror now. It's in the epoll branch ([EMAIL PROTECTED]/squid--epoll--3.0). Basic current outline is: 1) Remove accept defer limiting (done, via AcceptLimiter singleton). 1a) Make deferral calls into amount limiting calls throughout. 2) Ensure that all maybe-limiting deferred read hangler reads are *not scheduled*. (to do - audit begun). 3) remove *defer* calls. enlarging on 2)... we know for all FD's when we might want to defer the read - we can check this before scheduling the read, and instead place the reader in a queue, to be kicked off when the reason for the deferral changes (i.e. the delay bucket frees up space, or the client reads data reducing the read ahead gap). There is some serious work involved in 2), but should produce more scalable results: *) No checking for deferral on each io loop. *) Edge triggered approach, rather than level triggered. I think a variant on the AcceptLimiter class will make implementing 2) quite easy, once the read and edge detection logic is appropriately factored in each IO area. Rob -- GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
signature.asc
Description: This is a digitally signed message part
