Messages in this thread | | | Date | Fri, 19 Jan 2001 13:51:35 -0800 | From | Mike Kravetz <> | Subject | Re: [Lse-tech] Re: multi-queue scheduler update |
| |
On Fri, Jan 19, 2001 at 12:49:21PM -0800, Mike Kravetz showed his lack of internet slang understanding and wrote: > > It was my intention to post IIRC numbers for small thread counts today. > However, the benchmark (not the system) seems to hang on occasion. This > occurs on both the unmodified 2.4.0 kernel and the one which contains > my multi-queue patch. Therefore, I'm pretty sure it is not something > I did. :) > > Anyone else see anything like this before? I'll look into the reason > for the hang, but it will delay my posting of these numbers.
I think I have found the problem. Here is a code snippet from the benchmark Andrea posted.
void oneatwork(int thr) { int i; while (!start) /* don't disturb pthread_create() */ usleep(10000);
actthreads++; while (!stop) { if (count) totalwork[thr]++;
syscall(158); /* sys_sched_yield() */ } actthreads--; pthread_exit(0); }
Note that actthreads is a global variable which is being updated by multiple threads without any form of synchronization. Because of this actthreads sometimes never goes to zero after all worker threads have finished. I changed actthreads to be an atomic and used atomic operations to manipulate it. With this change, I was able to complete one round of testing which I had not been able to do in the past.
Does anyone maintain this benchmark code? The changes I indicate above should be made. If you need more specifics I can provide them.
-- Mike Kravetz mkravetz@sequent.com IBM Linux Technology Center - 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/
| |