Re: Add wakeup_with() before 7.0?

On Thu, 28 Jun 2007, John Baldwin wrote:

On Thursday 28 June 2007 03:41:15 pm Jeff Roberson wrote:
I propose to add a new api for wakeup before 7.0. This new api would
accept a wait channel and a flags argument. here's the relevant part of
the diff:

+void wakeup_with(void *chan, int flags) __nonnull(1);
+#define WAKEUP_ONE 0x00001 /* Only wakeup on thread.
*/
+#define WAKEUP_ALL 0x00002 /* Wake-up all waiters. */
+#define WAKEUP_LOCAL 0x00004 /* Wake-up on the local
cpu. */
+#define WAKEUP_TAIL 0x00008 /* Wake-up the newest
waiter. */

This allows wakeup callers to hint the scheduler about various
information. WAKEUP_LOCAL would allow us to prefer affinity for the
waking cpu. I have patches to use this in pipe code and socket buffer
code that improve performance in some workloads. WAKEUP_TAIL could be
used for accept() which I have heard can significantly improve webserver
performance.

To implement this change sched_wakeup() and setrunnable() need the flags
plummed all the way through. I would like feedback on whether people
think the api breakage should go in now to enable these optimizations for
7.0, potentially without committing users of these flags right away.
Alternatively we could break the api later or just skip it until 8.0.

We have something like WAKEUP_TAIL (but different, it also prefers non-swapped
out processes in addition to taking the most recently suspended thread) at
work for accept() and it just modifies the sleepq code's choice in
sleepq_signal() of which thread to pick, it doesn't touch any of the
scheduler stuff at all. OTOH, I think the scheduler ABIs are ok to change
during 7.x as they aren't exposed to any KLD's (no well-behaving ones anyway)
as drivers, etc. should all be using higher-level APIs like cv_*() or
*sleep().

In my implementation the WAKEUP_TAIL call just changes the sleepq as well. It doesn't go down to the scheduler. I agree that well behaving drivers should not use setrunnable() or sched_wakeup(). Maybe that is ok to break later. Any other opinions?

Jeff


--
John Baldwin

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Add wakeup_with() before 7.0?
    ... This allows wakeup callers to hint the scheduler about various ... waking cpu. ... To implement this change sched_wakeupand setrunnableneed the flags ... Alternatively we could break the api later or just skip it until 8.0. ...
    (freebsd-arch)
  • Re: RELENG_5 installworld fails
    ... > I just can't link problems with GCC optimization flags, ... killing the CPU and FLAGS are a place to start. ... Kent Stewart ...
    (freebsd-questions)
  • Re: [patch 05/10] Text Edit Lock - Alternative code for i386 and x86_64
    ... The common code should be in a common function. ... flags argument is passed without &. ... Should disable interrupts too just to be safer? ... interrupt handler will run with WP flag cleared on the CPU. ...
    (Linux-Kernel)
  • Re: incorrect ping(8) interval with powerd(8)
    ... :>: the desired amount of time. ... :> Those numbers look about right for a 200MHz CPU. ... If I use the flags "-i 1", I expect ECHO Requests to be sent ... If you ran it a second time would you get identical ...
    (freebsd-current)
  • [PATCH] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
    ... This also takes care of the differences between PPC and PPC64 cpu ... unsigned int real_instr; ... unsigned long flags; ...
    (Linux-Kernel)