1. using ioperm to give access to the parallel port.
2. have your program write a byte (thread id % 256 ?) constantly to the
port during it's other activity
3. capture the results from another computer with an ecp port
This way you don't run the risk of altering the scheduler behavior with
your logging procedure.
Mike Kravetz wrote:
> Last week while discussing scheduler benchmarks, Bill Hartner
> made a comment something like the following "the benchmark may
> not even be invoking the scheduler as you expect". This comment
> did not fully sink in until this weekend when I started thinking
> about changes made to sched_yield() in 2.4.0. (I'm cc'ing Ingo
> Molnar because I think he was involved in the changes). If you
> haven't taken a look at sys_sched_yield() in 2.4.0, I suggest
> that you do that now.
>
> A result of new optimizations made to sys_sched_yield() is that
> calling sched_yield() does not result in a 'reschedule' if there
> are no tasks waiting for CPU resources. Therefore, I would claim
> that running 'scheduler benchmarks' which loop doing sched_yield()
> seem to have little meaning/value for runs where the number of
> looping tasks is less than then number of CPUs in the system. Is
> that an accurate statement?
>
> If the above is accurate, then I am wondering what would be a
> good scheduler benchmark for these low task count situations.
> I could undo the optimizations in sys_sched_yield() (for testing
> purposes only!), and run the existing benchmarks. Can anyone
> suggest a better solution?
>
> Thanks,
-- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/