Re: [PATCH 1/6] Free up pf flag PF_KSOFTIRQD

[Eric Dumazet]

Le jeudi 21 octobre 2010 Ã 07:36 -0700, Venkatesh Pallipadi a Ãcrit :

> Yes. I thought about static inline part. The reason I did not make
> this static inline was because ksoftirqd was declared static in
> softirq.c and this function was getting called from sched.c.
> 

I believe you can remove the 'static' for this kind of thing.

> I did not know that this_cpu_read existed though. I guess I should be
> looking at using that elsewhere in the patchset too.
> 

Sure :)

> Also, part of the overhead you see below I think is coming from
> DEBUG_PREEMPT. That would be making every smp_processor_id() call more
> expensive. No?
> 

Right, but the point is the this_cpu_read() version doesnt have this
overhead, even if DEBUG_PREEMPT is on, at least on x86.

BTW, I lied somehow, because the way this_cpu_read() is handled,
following code :

	p == this_cpu_read(ksoftirqd);

generates :

mov     %gs:offset,%rax
cmp	%rdi,%rax

not :

cmp	%gs:offset,%rdi



--
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/