Re: epoll

2004-02-19 Thread Adrian Chadd
On Fri, Feb 20, 2004, Robert Collins wrote: > > Done. Can someone bootstrap it and commit it? I've got a few > > local hacks to get around the epoll linking that I'm thinking > > of cleaner ways around.. > > I think Henrik has that cron'd. Right. I thought something like that might be happening.

Re: epoll

2004-02-19 Thread Robert Collins
On Fri, 2004-02-20 at 14:28, Adrian Chadd wrote: > On Thu, Feb 19, 2004, Adrian Chadd wrote: > > On Fri, Feb 20, 2004, Robert Collins wrote: > > > > > just commit it. > > > > ok. > > > > Done. Can someone bootstrap it and commit it? I've got a few > local hacks to get around the epoll linking t

Re: epoll

2004-02-19 Thread Adrian Chadd
On Thu, Feb 19, 2004, Adrian Chadd wrote: > On Fri, Feb 20, 2004, Robert Collins wrote: > > > just commit it. > > ok. > Done. Can someone bootstrap it and commit it? I've got a few local hacks to get around the epoll linking that I'm thinking of cleaner ways around.. adrian

Re: epoll

2004-02-19 Thread Adrian Chadd
On Fri, Feb 20, 2004, Robert Collins wrote: > just commit it. ok. adrian

Re: epoll

2004-02-19 Thread Robert Collins
On Fri, 2004-02-20 at 14:19, Adrian Chadd wrote: > On Thu, Feb 19, 2004, David Nicklay wrote: > > Hi, > > > > I second Henrik's suggestion. The epoll stuff actually works on 2.4 > > kernels with a patch, and almost none of those have the new epoll stuff > > in glibc. > > > > Also, it would be

Re: epoll

2004-02-19 Thread Adrian Chadd
On Thu, Feb 19, 2004, David Nicklay wrote: > Hi, > > I second Henrik's suggestion. The epoll stuff actually works on 2.4 > kernels with a patch, and almost none of those have the new epoll stuff > in glibc. > > Also, it would be nice if someone could fix the autoconf scripts, so I > don't hav

Re: epoll

2004-02-19 Thread David Nicklay
Hi, I second Henrik's suggestion. The epoll stuff actually works on 2.4 kernels with a patch, and almost none of those have the new epoll stuff in glibc. Also, it would be nice if someone could fix the autoconf scripts, so I don't have to do: --disable-select --disable-poll --enable-epoll I

Re: auth_user_hash_pointer leak? (2.5 Bug #910)

2004-02-19 Thread Robert Collins
On Thu, 2004-02-19 at 21:50, Henrik Nordstrom wrote: > For challenge-reuse configurations it is still good but needs to purge old > entries when the challenge is changed. Will look into this. Well yes - the point is to cache some reasonable count for efficiency. But when a challenge changes, entri

Re: auth_user_hash_pointer leak? (2.5 Bug #910)

2004-02-19 Thread Henrik Nordstrom
On Thu, 19 Feb 2004, Robert Collins wrote: > On Thu, 2004-02-19 at 03:04, Henrik Nordstrom wrote: > > challenge-response caching: if the challenge given by the helper is the > same, and the response is the same, it's a valid login a priori. Ok. The use of this then obviously should be disabled i

Re: auth_user_hash_pointer leak? (2.5 Bug #910)

2004-02-19 Thread Robert Collins
On Thu, 2004-02-19 at 03:04, Henrik Nordstrom wrote: > Robert, what is the purpose of the auth_user_hash_pointer in the ntlm > scheme, and do you have any idea as to why the use of this would be > growing a lot? challenge-response caching: if the challenge given by the helper is the same, and the

Re: Re: Re: How dose pipe work in aufs ?

2004-02-19 Thread Henrik Nordstrom
On Thu, 19 Feb 2004, Xia Hongtao wrote: > Maybe in my test environment, the response time not effected by fs I/O so much. > I used polygraph 2.6.7, 1000 robots * 0.2 req/sec * 13KB , cacheable=100%, > recurrence=100%. > So the content will always in memory. What does access.log say about the hit

Re: Re: Re: How dose pipe work in aufs ?

2004-02-19 Thread Henrik Nordstrom
On Thu, 19 Feb 2004, Xia Hongtao wrote: > So in current 2.5.STABLE4 version, just the first 4KB fs I/O was done by > asyncronous threads? If the content is larger then 4KB, the main squid thread > will do the fs I/O remained ? The functions in disk.c is not at all used for aufs disk I/O. These