Re: per cpun+ spin locks coexistence?

On Wed, Mar 19, 2008 at 01:00:27AM +0800, Peter Teoh wrote:
First, the following is possible:

fddef = &get_cpu_var(fdtable_defer_list);
spin_lock(&fddef->lock);
fdt->next = fddef->next;
fddef->next = fdt;==============>executing at CPU A
/* vmallocs are handled from the workqueue context */
schedule_work(&fddef->wq);
spin_unlock(&fddef->lock);==============>executing at CPU B
put_cpu_var(fdtable_defer_list);

where the execution can switch CPU after the schedule_work() API, then
LOGICALLY u definitely need the spin_lock(), and the per_cpu data is
really not necessary.

But without the per_cpu structure, then the following "dedicated
chunk" can only execute on one processor, with the possibility of
switching to another processor after schedule_work():

Wrong. You cannot switch to another processor in schedule_work(),
it doesn't block. Just read the code.

The reason why I used a per-cpu fdtable_defer_list is that I
did not want to make it a global list of deferred fdtable
structures to be freed and then have to protect it by a global lock.
Every fdtable free would have had to take the same global lock
in that case and this would have resulted in scalability
issues (cacheline bouncing, lock contention). Instead,
I used a per-cpu list in essence creating finer-grain locking.
Two CPUs doing fdtable free operations simultaneously will
not contend for the same lock in this case. The fddef lock
is still required for the reasons Eric pointed out.


and per_cpu is so that the same chunk of code can be executing at
multiple CPUs all at the same time.

Now the key issue rises up - as I have just asked before u answered my question:

http://mail.nl.linux.org/kernelnewbies/2008-03/msg00236.html

can schedule_work() sleep? (just like schedule(), whcih can sleep right?)
schedule_work() is guaranteed to execute the work queue at least once,
and so this thread may or may not sleep. correct? Or wrong?

Wrong.

Thanks
Dipankar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: lock
    ... is one of the internal hidden registers within the ... of various CPUs. ... Someplace it says that lock is active ... always prefix your code with LOCK (even though it's implied for memory ...
    (alt.lang.asm)
  • Re: Where do the gains of OOO architecture actually take effect?
    ... I recall seeing a dramatic performance increase on EV6. ... CPUs' hardware and allow the fairest comparison, ... probably execute very rarely. ... the scheduling of the binary's instruction stream onto one of the CPUs. ...
    (comp.arch)
  • Re: a few issues with events
    ... the compiler or JIT engine should always be able to check if a thing is null and just not execute the code using the null reference. ... Of course, this would lead to problems where code silently fails when a reference is null, in many cases simply not executing code that's very important to execute. ... you should never lock on "this" anyway. ... If you want a thread blocked on Jointo process messages, you will probably have to use p/invoke to get at the SendMessagefunction directly, and also override the WndProc method in your Form class so that you can receive the message sent by SendMessage. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: 74 Archer ignition switch question
    ... News flash...I removed and disassembled the switch as suggested. ... fragments laying on the rag. ... the outer corner of the trough the lock tumblers locked into was eroded. ... Wag also has new units (push to start and the other kind). ...
    (rec.aviation.owning)
  • Lock profiling results on TCP and an 8.x project
    ... I've started to look at decomposing tcbinfo, and preparatory to that, I ran some lock profiling on simple TCP workloads to explore where and how contention is arising. ... These results appear to confirm that we need to look at breaking out the tcbinfo lock as a key goal for 8.0, with serious thoughts about an MFC once stabilized and if ABI-safe--these two workloads represent the extremes of TCP workloads, and real world configurations will fall in between, but as the number of cores goes up and the desire to spread work over CPUs goes up, so will contention on a single global lock. ...
    (freebsd-arch)