[lkml]   [2002]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 2.5.21 Nonlinear CPU support
Followup to:  <>
By author: Anton Altaparmakov <>
In newsgroup:
> >2) If you need to do decompression on a cpu you check the array entry
> > for that CPU and if is NULL you vmalloc() the decompression buffers once
> > for that CPU. This avoid vmalloc() overhead for each read.
> The vmalloc() sleeps and by the time you get control back you are executing
> on a different CPU. Ooops. The only valid way of treating per-cpu data is:
> - disable preemption
> - get the cpu number = START OF CRITICAL SECTION: no sleep/schedule allowed
> - do work using the cpu number
> - reenable preemption = END OF CRITICAL SECTION

Actually, that doesn't matter, because it's a quickly convergent

Basically, once you've been invoked on a particular CPU once, you are
pretty much guaranteed to get invoked on that same CPU again, so the
fact that you may end up using a different buffer post-allocation is
not an issue.

Have an array and a semaphore called here allocation_semaphore:


while ( 1 ) {
cpu = current_cpu();
if ( decompression_buffers[cpu] ) {
break; /* DONE, EXIT LOOP */
} else {
/* Avoid race condition here */
if ( !decompression_buffers[cpu] )
decompression_buffers[cpu] = vmalloc(BUFFER_SIZE);

Note that there is no requirement that we're still on cpu "cpu" when
we allocate the buffer. Furthermore, if we fail, we just loop right
back to the top.


<> at work, <> in private!
"Unix gives you enough rope to shoot yourself in the foot." <>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.063 / U:9.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site