On Tue, 2002-06-04 at 10:38, Simon Trimmer wrote:
> Hi Robert,
> This isn't my thing but my flatmate had left a copy of solaris internals on
> the table ;)
>
> This is briefly mentioned around about page 384 and appears to be targetted
> at userspace processes for exactly the cases you're suggesting (holding
> global resources).
I knew I read it there ;) My copy of "Solaris Internals" is elsewhere so
I could not confirm.
> A good entry point into the sun online documentation for this stuff is
> schedctl_init() -
> http://docs.sun.com/db?q=schedctl_init&p=/doc/816-0216/6m6ngupm0&a=view
Hm, what they export is a bit different. I wonder what the internal
kernel interface is like (i.e. how close to sched_hint it is)?
Since they have a start_hint and stop_hint, that is where they are able
to enforce their fairness. When you call stop, I suspect they penalize
your timeslice by some amount similar to the duration from start to
stop. If you don't call stop before you reschedule, then you probably
forfeit a large chunk of your timeslice.
This would be doable with our scheduler - and perhaps even with minimal
impact (which is my goal). However, since I wrote this more as an
exercise in fun than something to merge, I do not know if it is worth it
to make a whole infrastructure around this. Those who really see
benefit (scientific computing or real-time or whatever) could just grab
the patch, remove the permission check, and code their applications to
fit -- they trust their application base.
Anyhow, to pique interest, here are some benchmark numbers. I have 5
pthreads contesting over a single semaphore. They loop, doing some busy
looping, down the semaphore, busy loop, and then up the semaphore. Thus
they use a lot of their timeslice and spend the rest of the time
blocking on the semaphore. I let them loop a fixed number of times
before exiting.
(These are average of ~10 runs)
With a call to sched_hint(HINT_TIME) after successfully downing the
semaphore the avg total duration is 7233459 us. Without the sched_hint,
the avg total duration is 7683220 us.
That is an improvement of 6% - with only 5 threads.
A quick glance shows a reduction in context switches, but what really
matters is if we are entering schedule and neither (a) rescheduling the
same task, or (b) running another thread that quickly blocks on the
semaphore.
It is all academic anyhow...
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 07 2002 - 22:00:21 EST