On Thu, 17 Mar 2005, Adrian Chadd wrote:
> Just as a FWIW, this is something thats been discussed to death a couple
> of years ago. Yup, event driven IO doesn't play well with the current
> defer processing of IO.
Indeed. There needs to be a soft event triggering the fd alive again,
driven by the consumers.
Should be trivial to add ontop of the changes already done in the lfs
branch.. There is already a notifier going from the store clients to the
store to clean up the cache vm. Just need to kill some of the
optimizations.
> it would. I'd like to finally get back into this now - doubly so if there's
> someone else here who is interested in fixing the network IO code path
> in squid-2.5.
It certainly would be good to have it fixed in the epoll branch.. But we
should first fix it in Squid-3 I think..
Note: The lfs branch is out of necessity in core functionality as multi-GB
files is starting to become increasingly common on FTP servers etc, not
performance. I had to touch this area due to race windows opened by the
large object changes while fixing and old bug involving joined requests
where Squid would to try to allocate virtually unlimited amount of space
in the on-disk cache. Without the large object changes this bug was not so
bad as it was limited to allocate at most 2GB per object, but this is no
longer true...
Regards
Henrik
Received on Wed Mar 16 2005 - 18:50:43 MST
This archive was generated by hypermail pre-2.1.9 : Fri Apr 01 2005 - 12:00:04 MST