Re: Deferred reads

On Thu, 1 Jun 2000, Adrian Chadd wrote:
 
> I have been doing my testing with a datacomm-1 polygraph load. I will

Polygraph is probably not the best way to test deferred reads. Especially
with the datacomm-1 workload, clients always read as fast as they can.
Datacomm-1 doesn't simulate fast servers and slow clients. It might
be hard to simulate fast servers and slow clients with polygraph.
 
> > Also, can you explain what a properly scheduled read is?
> > How is that supposed to work?
>
> For example, only scheduling a read when you only want data, and not
> when its deferred. I'll pull up some example code to demonstrate what
> I'm thinking.

So via eventAdd() etc?

> The trouble is that in poll/select, you can throw away a returned
> fd rather easily because you should have all the other fds that are
> ready to service, and you only sacrifice a little CPU. With an event

Are you talking about a world without deferred reads, and you select
a FD, it returns ready for reading, but you just dont read? That
does not work well at all. It can cause a mostly idle cache to
use a lot of CPU.

> driven system like kqueue, if you throw away the read because you are
> not ready to deal with it yet (a la deferred reads), you schedule
> another one and it will return immediately. If you end up with
> a few deferred reads, then you end up getting mostly these read ready
> fds. kqueue doesn't have any way of dealing with this. You can't
> tell whether a fd is going to be deferred at event add time, and you
> don't get an update when the read defer is active and inactive.

One might argue its a limitation/deficiency of the kqueue implementation.
Can't you just schedule the kqueue event only when you want data?

Duane W.
Received on Wed May 31 2000 - 14:59:21 MDT