Hubertus wrote :
> The only problem I have with sched_yield like benchmarks is that it
creates
> artificial lock contention as we basically spent most of the time other
> then context switching + syscall under the scheduler lock. This we won't
> see in real apps, that's why I think the chatroom
o, you can control the number of threads in the RUN state,
and you exercise the wakeup code. Your numbers will be
diluted by the overhead in semop(). The metric would be
how many wakeups done by each thread.
Is there a better API that could accomplish the same
wakeup someone up and then sleep sem
in the run. The benchmark may produce more consistent results
from run to run (assuming what I suspect is going on is really the
case).
You mileage may vary.
Thoughts ?
Bill Hartner
IBM Linux Technology Center - kernel performance
[EMAIL PROTECTED]
--from kernel/sch
124 62
inode_cache 355257 355257448 39473 394731 : 124 62
inode_cache 355446 355446448 39494 394941 : 124 62
inode_cache 355464 355464448 39496 394961 : 124 62
inode_cache 355420 355482448 39495 39498 1 : 124 62
...
Bill Hartner
4 matches
Mail list logo
