lkml.org 
[lkml]   [2008]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: per cpun+ spin locks coexistence?
Thanks for the answer.   But I still don't get it.

On Sat, Mar 15, 2008 at 1:54 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> Peter Teoh wrote:
> > Help me out this one - in fs/file.c, there is a function free_fdtable_rcu():
> >
> > void free_fdtable_rcu(struct rcu_head *rcu)
> > {
> > struct fdtable *fdt = container_of(rcu, struct fdtable, rcu);
> > struct fdtable_defer *fddef;
> >
> > BUG_ON(!fdt);
> >
> > if (fdt->max_fds <= NR_OPEN_DEFAULT) {
> > /*
> > * This fdtable is embedded in the files structure and that
> > * structure itself is getting destroyed.
> > */
> > kmem_cache_free(files_cachep,
> > container_of(fdt, struct files_struct,
> > fdtab));
> > return;
> > }
> > if (fdt->max_fds <= (PAGE_SIZE / sizeof(struct file *))) {
> > kfree(fdt->fd);
> > kfree(fdt->open_fds);
> > kfree(fdt);
> > } else {
> > fddef = &get_cpu_var(fdtable_defer_list);
> > spin_lock(&fddef->lock);
> > fdt->next = fddef->next;
> > fddef->next = fdt;
> > /* vmallocs are handled from the workqueue context */
> > schedule_work(&fddef->wq);
> > spin_unlock(&fddef->lock);
> > put_cpu_var(fdtable_defer_list);
> > }
> > }
> >
> > Notice above that get_cpu_var() is followed by spin_lock(). Does this
> > make sense? get_cpu_var() will return a variable that is only
> > accessible by the current CPU - guaranteed it will not be touch (read or
> > write) by another CPU, right?
>
> No, not true. percpu is for stuff which is generally only touched by
> one CPU, but there's nothing stopping other processors from accessing it
> with per_cpu(var, cpu).

get_cpu_var() above, will return a ptr specific for a particular CPU
only, is correct?

#define get_cpu_var(var) (*({ \
extern int simple_identifier_##var(void); \
preempt_disable(); \
&__get_cpu_var(var); }))

SMP:

#define __get_cpu_var(var) \
(*SHIFT_PERCPU_PTR(&per_cpu_var(var), my_cpu_offset))

#define SHIFT_PERCPU_PTR(__p, __offset) RELOC_HIDE((__p), (__offset))

and RELOC_HIDE() i don't understand. So from what u said,
per_cpu_var() returns uniquely for each CPU, but __get_cpu_var() may
not be unique among the different CPU - is that correct?

When cpuA and cpuB call get_cpu_var(), the returned ptr is specific
only for cpuA and cpuB, right? So yes, as u said, different cpu can
call get_cpu_var(), but the returned ptr will be unique to each cpu,
therefore it is guaranteed that another CPU will not get hold of the
returned results of get_cpu_var(), right? So why spin_lock() comes
after get_cpu_var()?

>
> Besides, the lock isn't locking the percpu list head, but the thing on
> the head of the list, presumably to prevent races with the workqueue.

I think I have something much deeper to learn. Can u point me to
some resources to read more about this?
I don't understand the difference betw locking the percpu list head,
and locking things on the head of the list. For me, spin_lock() is
always to apply on ANY global variable - so that another cpu will
block when access to it is attempted - whether it is items on a list,
ot head of the list etc.

> (Though the list structure is nonstandard, so its not completely clear.)
>
> J

Thank you in advance for the all the help rendered, :=).

--
Regards,
Peter Teoh


\
 
 \ /
  Last update: 2008-03-16 17:33    [W:0.593 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site