Re: Deferred reads

On Wed, May 31, 2000, Duane Wessels 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.

Point taken. Got any pointers on how I can simulate this? 'm ot in
a position to test this code in a production environment right now ..

> > > 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?

No.. for the http client/server setup, a read would be scheduled only
when the clients aren't too far behind. If they are, the read isn't
scheduled. Then (this is the bit that isn't easy right now..) when
a client is below the readahead threshold, the read is scheduled again.

> > 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.

As we've seen. :-P

> > 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?

Define 'when you want data' .. the problem with the deferred reads in an
event driven system is that the deferred read condition is polled, and
so there is a way when commSetSelect(fd, COMM_SELECT_READ, handler..) is
called to know whether the deferred read condition is preventing a read
being scheduled, but there is no notification that the deferred reda
condition is over. Think of what I'm tossing around as 'notification
based deferred reads' .. instead of scheduling a read and then polling
the deferred read condition, the read is scheduled only when the deferred
read condition is false, not scheduled when it is true, and a transition
between being deferred and not being deferred (or vice versa) will trigger
the relevant read beig scheduled or unscheduled.

Adrian

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.