Question about "barrier()" in the SLUB's fast path
Hi, Recently, I had difficulty understanding the meaning of the barrier() in the slab_alloc_node(). The comments are written like this. /* * Irqless object alloc/free algorithm used here depends on sequence * of fetching cpu_slab's data. tid should be fetched before anything * on c to guarantee that object and page associated with previous tid * won't be used with current tid. If we fetch tid first, object and * page could be one associated with next tid and our alloc/free * request will be failed. In this case, we will retry. So, no problem. */ barrier(); Even if we don't fetch tid first, don't we try again by this_cpu_cmpxchg_double? I'd really appreciate it if you let me know what I missed! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why a “barrier()” is enough for disabling or enabling the preemption?
> #define preempt_disable() barrier() > .. > #define preempt_enable() barrier() Let me try answering this with a limited knowledge I have about barriers. barrier() essentially was added so that compiler reordering does not happen. In the code above, since the compiler does not know/understand the specialty of preempt_[enable/disable], the compiler might decide to change the ordering. In this case, where the code is disabling/enabling preemption, barrier() tells the compiler that it can't move stuff around. I hope this helps. - Doug ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Why a “barrier()” is enough for disabling or enabling the preemption?
Hi all,
Below is the preemption disable/enable code:
#ifdef CONFIG_PREEMPT_COUNT
#define preempt_disable() \
do { \
inc_preempt_count(); \
barrier(); \
} while (0)
..
#define preempt_enable() \
do { \
preempt_enable_no_resched(); \
barrier(); \
preempt_check_resched(); \
} while (0)
#else /* !CONFIG_PREEMPT_COUNT */
/*
* Even if we don't have any preemption, we need preempt disable/enable
* to be barriers, so that we don't have things like get_user/put_user
* that can cause faults and scheduling migrate into our preempt-protected
* region.
*/
#define preempt_disable() barrier()
..
#define preempt_enable() barrier()
..
#endif /* CONFIG_PREEMPT_COUNT */
And I have a question about it:If the CONFIG_PREEMPT_COUNT is OFF,
while CONFIG_PREEMPT is ON,
why only a barrier()can disable/enable preemption? What is the magic
behind it? Or On SMP, the
CONFIG_PREEMPT_COUNT should always be ON?
BTW, I also post this issue on
SO(http://stackoverflow.com/questions/33864903/why-a-barrier-is-enough-for-disabling-or-enabling-the-preemption),
but can't receive clear answers.
Thanks in advance!
Best Regards
Nan Xiao
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: barrier()
-Original Message-
From: kernelnewbies-
bounces+pranay.shrivastava=hcl@kernelnewbies.org
[mailto:kernelnewbies-
bounces+pranay.shrivastava=hcl@kernelnewbies.org] On Behalf Of
kernelnewbies-requ...@kernelnewbies.org
Sent: Monday, February 25, 2013 12:55 PM
To: kernelnewbies@kernelnewbies.org
Subject: Kernelnewbies Digest, Vol 27, Issue 52
Send Kernelnewbies mailing list submissions to
kernelnewbies@kernelnewbies.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
or, via email, send a message with subject or body 'help' to
kernelnewbies-requ...@kernelnewbies.org
You can reach the person managing the list at
kernelnewbies-ow...@kernelnewbies.org
When replying, please edit your Subject line so it is more specific than Re:
Contents of Kernelnewbies digest...
Today's Topics:
1. Re: atomic operations (valdis.kletni...@vt.edu)
2. valid address space ? (Abu Rasheda)
3. Re: valid address space ? (Abu Rasheda)
4. barrier() (Shraddha Kamat)
5. Re: test jiffies on ARM SMP board (bill4carson)
6. Re: test jiffies on ARM SMP board (bill4carson)
7. Re: atomic operations (Kumar amit mehta)
8. (Prasad Lakshman)
--
Message: 1
Date: Sun, 24 Feb 2013 18:24:21 -0500
From: valdis.kletni...@vt.edu
Subject: Re: atomic operations
To: richard -rw- weinberger richard.weinber...@gmail.com
Cc: Shraddha Kamat sh200...@gmail.com, kernelnewbies
kernelnewbies@kernelnewbies.org
Message-ID: 6017.1361748...@turing-police.cc.vt.edu
Content-Type: text/plain; charset=us-ascii
On Sun, 24 Feb 2013 11:50:14 +0100, richard -rw- weinberger said:
On Sun, Feb 24, 2013 at 10:42 AM, Shraddha Kamat sh200...@gmail.com
wrote:
what is the relation between atomic operations and memory alignment ?
I read from UTLK that an unaligned memory access is not atomic
please explain me , I am not able to get the relationship between
memory alignment and atomicity of the operation.
Not all CPUs support unaligned memory access, such an access may cause
a fault which needs to be fixed by the kernel...
There's a more subtle issue - an unaligned access can be split across a cache
line boundary, requiring 2 separate memory accesses to do the read or write.
This can result in CPU A fetching the first half of the variable, CPU B
updating
both halves, and then A fetching the second half of the now updated
variable.. This can bite you even on CPUs that support unaligned accesses.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url :
http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
224/d2bc34b0/attachment-0001.bin
--
Message: 2
Date: Sun, 24 Feb 2013 19:24:10 -0800
From: Abu Rasheda rcpilot2...@gmail.com
Subject: valid address space ?
To: Linux Kernel List kernelnewbies@kernelnewbies.org
Message-ID:
CACYKDtgw5+8HdSaKgVSN6S7qT-NkiQr=w-
wda0c+1duigcd...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1
I am trying to dump some kernel data structure (walk e.g. task or file data
structure on x86_64 arch). Sometime accessing through a pointer, pointer
may not be NULL, but pointing to invalid address due to garbage value.
What I am looking for is range of address which are valid for kernel data
structure. Is it correct to say following address are valid ?
- Bit 0 - 47 are considered
- Between 8000' through '
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
224/bfaaacb1/attachment-0001.html
--
Message: 3
Date: Sun, 24 Feb 2013 21:37:48 -0800
From: Abu Rasheda rcpilot2...@gmail.com
Subject: Re: valid address space ?
To: Linux Kernel List kernelnewbies@kernelnewbies.org
Message-ID:
CACYKDth+Lv87TmJXGK8tWUmREhrkrT5t9-
gyftcazh8svtw...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1
On Sunday, February 24, 2013, Abu Rasheda wrote:
I am trying to dump some kernel data structure (walk e.g. task or file
data structure on x86_64 arch). Sometime accessing through a pointer,
pointer may not be NULL, but pointing to invalid address due to
garbage value.
What I am looking for is range of address which are valid for kernel
data structure. Is it correct to say following address are valid ?
- Bit 0 - 47 are considered
- Between 8000' through '
Will this cover all situations
if (long_ptr 0x1000)
{
tmp_long_ptr = ((long_ptr 0x8000) ? (long_ptr |
0x8000) : (long_ptr 0x
barrier()
#define barrier() asm volatile( ::: memory) What exactly volatile( ::: memory) doing here ? I was referring to gnu as (ver 2.14) manual but could not get much clue about this assembly construct - any pointers ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: barrier()
On Mon, 25 Feb 2013 12:26:06 +0530, Shraddha Kamat said: #define barrier() asm volatile( ::: memory) What exactly volatile( ::: memory) doing here ? You probably should read Documentation/memory-barriers.txt in your kernel source tree, and let us know if you still have questions after that... pgpYDJoYxqUZ5.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Memory barrier
Hi, In my opinion it is not correct to say make order on current CPU in case of SMP. Actually, we cope with shared resource here - memory, and observes for that resource - CPUs. As soon as CPU is asked to make a barrier (with some sort of instruction) access to shared resource is ordered among all of observers. So, in case of SMP we have to protect shared resource with hardware memory barriers. In case of UP, memory is not shared, so, generally, we have to take care that memory access won't be optimized by compiler. P.S. Sorry for digging this thread. Best wishes Vladimir Murzin On 12/9/11, 卜弋天 bu...@live.cn wrote: Hi : if you write code as below: golbal int in1=0,int2=0; cpu1: cpu2: int1 = 1; b= int2; smp_wmb() int2 = 2; a = in1; cpu2 may get the result: b==2 a==0 , which means although cpu1 set int1=1 before int2=2, there is no garentee for cpu2 to perceive int1 before int2. you must add smp_rmb() inside cpu2 to prevent this. two cpus must cooperate to acheive the sequence memory order. Date: Fri, 9 Dec 2011 14:14:37 +0530 Subject: Re: Memory barrier From: trisha1ma...@gmail.com To: bu...@live.cn CC: kernelnewbies@kernelnewbies.org I will add more info here: smp_mb() Similar to mb(), but only guarantees ordering between cores/processors within an SMP system. All memory accesses before the smp_mb() will be visible to all cores within the SMP system before any accesses after the smp_mb(). smp_rmb() Like smp_mb(), but only guarantees ordering between read accesses. smp_wmb() Like smp_mb(), but only guarantees ordering between write accesses. So these made me total confuse . Thanks 2011/12/9 trisha yad trisha1ma...@gmail.com: Thanks, I got bit confuse with below statement: This is from paper Memory access ordering Part 2 SMP conditional barriers The SMP conditional barriers are used to ensure a consistent view of memory between different cores within a cache coherent SMP system. When compiling a kernel without CONFIG_SMP, all SMP barriers are converted into plain compiler barriers. 2011/12/9 卜弋天 bu...@live.cn: Hi : memory barriers can not make order on other cpus, only the current cpu's order will be promised. Date: Fri, 9 Dec 2011 12:54:40 +0530 Subject: Memory barrier From: trisha1ma...@gmail.com To: Kernelnewbies@kernelnewbies.org Hi All, I need small clarification on memory barrier. #define smp_mb() mb() #define smp_rmb() rmb() #define smp_wmb() wmb() In case of SMP: is smp_mb() or smp_rmb() make order on current CPU or all cpu's Thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: memory barrier in UP
Hi... On Mon, Dec 12, 2011 at 01:11, subin gangadharan subingangadha...@gmail.com wrote: Hi All, I am reading about the barrier from linux kernel development.In this books, he says On SMP kernels they are defined only as usual memory barriers.where as on UP kernels they are defined only as a compiler barrier Does this mean in UP, processor won't reorder the instructions ? In some arch like Alpha, loosely reordering even in UP could happen at any time. But in x86 UP, IIRC there's only strict re-ordering, meaning that every read is always fetching latest write etc. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: memory barrier in UP
Hi Mulyadi, Thanks for the answer. On Mon, Dec 12, 2011 at 11:16 AM, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: Hi... On Mon, Dec 12, 2011 at 01:11, subin gangadharan subingangadha...@gmail.com wrote: Hi All, I am reading about the barrier from linux kernel development.In this books, he says On SMP kernels they are defined only as usual memory barriers.where as on UP kernels they are defined only as a compiler barrier Does this mean in UP, processor won't reorder the instructions ? In some arch like Alpha, loosely reordering even in UP could happen at any time. But in x86 UP, IIRC there's only strict re-ordering, meaning that every read is always fetching latest write etc. In that case (ALPHA), is compiler barrier sufficient enough to prevent the re ordering done by the processor. What I was thinking,compiler barrier is to instruct the compiler to not do any re ordering. Please correct me if I am wrong. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- With Regards Subin Gangadharan I am not afraid and I am also not afraid of being afraid. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: memory barrier in UP
Hi Subin On Tue, Dec 13, 2011 at 01:57, subin gangadharan subingangadha...@gmail.com wrote: Hi Mulyadi, Thanks for the answer. You welcome...I just shared what I know :) In that case (ALPHA), is compiler barrier sufficient enough to prevent the re ordering done by the processor. What I was thinking,compiler barrier is to instruct the compiler to not do any re ordering. Again this is architecture problem. I am not sure about Alpha, since I only know about one compiler barrier that is volatile. What I guess is that in Alpha, it could be something elsemaybe it is assembly instruction like lock or something. I remember there's an old Linuxjournal article that explains about it. So to avoid further misunderstandings that I might bring, please kindly read this article: http://www.linuxjournal.com/article/8212 Hope that helps... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
memory barrier in UP
Hi All, I am reading about the barrier from linux kernel development.In this books, he says On SMP kernels they are defined only as usual memory barriers.where as on UP kernels they are defined only as a compiler barrier Does this mean in UP, processor won't reorder the instructions ? Could please give any idea on this. -- With Regards Subin Gangadharan I am not afraid and I am also not afraid of being afraid. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Memory barrier
Hi All, I need small clarification on memory barrier. #define smp_mb() mb() #define smp_rmb() rmb() #define smp_wmb() wmb() In case of SMP: is smp_mb() or smp_rmb() make order on current CPU or all cpu's Thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
