On Thu, Aug 18, 2005 at 02:50:16AM +0200, Bernardo Innocenti wrote:
> The relative timestamp reveals that slapd is spending 50ms
> after yielding. Meanwhile, GCC is probably being scheduled
> for a whole quantum.
>
> Reading the man-page of sched_yield() it seems this isn't
> the correct behavior:
>
> Note: If the current process is the only process in the
> highest priority list at that time, this process will
> continue to run after a call to sched_yield.
The behavior of sched_yield changed for 2.6. I suppose the man
page didn't get updated.
>From linux/Documentation/post-halloween.txt:
| - The behavior of sched_yield() changed a lot. A task that uses
| this system call should now expect to sleep for possibly a very
| long time. Tasks that do not really desire to give up the
| processor for a while should probably not make heavy use of this
| function. Unfortunately, some GUI programs (like Open Office)
| do make excessive use of this call and under load their
| performance is poor. It seems this new 2.6 behavior is optimal
| but some user-space applications may need fixing.
This is pretty much all I know about it; I just thought I'd point
it out.
> I also think OpenLDAP is wrong. First, it should be calling
> pthread_yield() because slapd is a multithreading process
> and it just wants to run the other threads. See:
Is it possible that this problem has been noticed and fixed
already?
--
Joseph Fannin
[EMAIL PROTECTED]
/* So there I am, in the middle of my `netfilter-is-wonderful'
talk in Sydney, and someone asks `What happens if you try
to enlarge a 64k packet here?'. I think I said something
eloquent like `fuck'. - RR */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
