On Mon, 03 Jul 2006 20:13:36 -0400
Shailabh Nagar <[email protected]> wrote:
> >>+ if (!s)
> >>+ return -ENOMEM;
> >>+ s->pid = pid;
> >>+ INIT_LIST_HEAD(&s->list);
> >>+
> >>+ down_write(sem);
> >>+ list_add(&s->list, head);
> >>+ up_write(sem);
> >>+
> >>+ if (cpu == mycpu)
> >>+ preempt_enable();
> >>
> >>
> >
> >Actually, I don't understand the tricks which are going on with the local CPU here.
> >What's it all for?
> >
> >
> I was wanting to do a get_cpu_var for listener_list & sem
> for the current cpu and per_cpu otherwise (since thats what I thought
> was the recommendation
> for accessing the local cpu's variable). Perhaps the preempt_disable is
> uncalled for ?
Well we have a problem. You want to grab this CPU's list, and then lock a
semaphore. But taking a semaphore is a sleeping operation.
Fortunately, there's really no need to stay on-CPU at all. When userspace
is setting or clearing entries in the map, userspace _told_ us which CPU to
manipulate, so this code can be running on any CPU at all. So just go grab
the Nth entry in the array and acquire the lock.
And when the time comes to send some statistics, just use
raw_smp_processor_id() and don't use preempt_disable() at all. If we end
up hopping over to another CPU, well at least we tried. All we can do here
is to run raw_smp_processor_id() as early as possible to reduce the
possibility that we'll get a different CPU from the one which this task
really exited on.
IOW: in all cases we were provided with explicit CPU numbers from other
sources. So no preemption disabling is required.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]