Re: from WHERE platform driver's probe is called?
On Thu, Nov 27, 2014 at 1:00 AM, Sunil Shahu wrote: > Hi Daniel, > Thanks, dump_stack() is what I needed. > > Hi Subin, > Thanks for the snapshot. > > Also, I am attaching a graph for what I understood after following > dump_stack(). > > Please let me know if there is any issue with the flow. > > Thanks, > Sunil. > > > > On Saturday, 22 November 2014 9:04 AM, subin gangadharan > wrote: > > > Hi Sunil, > >>>I am still not able to locate from WHERE this probe function is called and >>> WHO calls it? > > I can try to give you a snapshot of the function call trace. But if > you really want to get in depth detail, as Greg said look at the code > driver/base. > > driver_register > ->bus_add_driver->driver_attach->__driver_attach->driver_probe_device->really_probe->drv->probe > > Basically when you register your platform driver, the platform > bus(platform_bus_type) will scan for the matching device. If you look > at the platform_bus_type structure you can find the match function > which does the matching of driver and device. Once it's found the > right device, it will attach the driver to the device.Look at the > function driver_attach. And if you look at the > platform_driver_register function, you can see that > "platform_drv_probe" function is assigned to driver.probe function. > And this probe function will finally call your registered platform > driver probe function. > > Hope this helps. > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > Hi Sunil, Thanks for the nice detailed snap shot. Subin ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: from WHERE platform driver's probe is called?
Hi Sunil, >>I am still not able to locate from WHERE this probe function is called and >>WHO calls it? I can try to give you a snapshot of the function call trace. But if you really want to get in depth detail, as Greg said look at the code driver/base. driver_register ->bus_add_driver->driver_attach->__driver_attach->driver_probe_device->really_probe->drv->probe Basically when you register your platform driver, the platform bus(platform_bus_type) will scan for the matching device. If you look at the platform_bus_type structure you can find the match function which does the matching of driver and device. Once it's found the right device, it will attach the driver to the device.Look at the function driver_attach. And if you look at the platform_driver_register function, you can see that "platform_drv_probe" function is assigned to driver.probe function. And this probe function will finally call your registered platform driver probe function. Hope this helps. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: identity mapped paging
Hi Vaibhav, > identity mappings no longer useful.According to this article > http://geezer.osdevbrasil.net/osd/mem/index.htm#identity - "The page table > entries used to identity-map kernel memory can be deleted once paging and > virtual addresses are enabled." Can somebody please explain? I don't have a good idea on this. But my guess is, these entries has to there to enable MMU. Because after enabling it you are still in the same address space. Basically kernel needs an x to x translation(identity mapping) before kernel do the jump to the virtual space (0xc000 ), after that those entries are not needed any more. Will wait for our kernel experts comments. > > Thanks > Vaibhav Jain > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- 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: How to avoid kernel Oops 0x81F in function do_alignment() ?
Hi, > 2. how can i change the page permisson before write back instruction of > user mode application? > for example, find out the page tables of current application, find out > the pte which represents > the instruction that generate data abort, then modify pte, write back > instruction, restore pte, done. > how to do these? I think you can get the pgd of this process by current->mm->pgd and pgd_offset macro to ge the pgd entry for that address. There are macros available for accessing pmd and pte too. For example pte_offset_map for pte and a locking version for the same is also there. I don't have any hands on experience on this, so our kernel experts can comment on this more. And one more thing, if you can look at the function handle_mm_fault (mm/memory.c), there are plenty of refererces for accesing these page table entries. With Regards, Subin K G > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- 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
remap_pfn_range doubt
Hi All, I am trying to understand how this remap_pfn_range is implemented. I almost got an idea on the implementation. However one thing is not clear, they always subtract userspace address pfn from the physican pfn (http://lxr.linux.no/#linux+v3.2.11/mm/memory.c#L2278) and then adding it back http://lxr.linux.no/#linux+v3.2.11/mm/memory.c#L2284 and calling the inside function. I don't understand why they are not directly passing it. Is there any specific reason for this. Could you please give some pointers 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
Re: pagetables used in interrupt context
Thanks a ton for all your help. 2012/2/26 弋天 卜 : > Hi: > > I think it is for safe,people can open interrupt inside their own interrupt > handler, so kernel must disable it before touch kernel data that must be > protected. > > > 在 2012-2-25，1:39，"subin gangadharan" 写道： > >> Hi 卜弋天, >> >>> 2.6.35, i checked the function handle_level_irq()and handle_edge_irq() in >>> chip.c, both of them will call handle_IRQ_event() which is in handle.c. and >>> the function handle_IRQ_event() will call the interrupt handler written by >>> user. Kernel does not open interrupt(ARM CPSR I bit)when calling interrupt >>> handler in handle_IRQ_event() function. >> >> Thank you for the valuable pointers. I have looked at the >> handle_IRQ_event function, it seems at the end of the do while loop >> its unconditionally disable the local interrupt (ARM CPSR I bit). If >> the handler is running with interrupts disabled, why do we need to >> disable the interrupts again. >> >> Could you please explain about this logic. >> >> Thanks in advance for your help and sorry to take up your time on this. >> >> >> >> -- >> With Regards >> Subin Gangadharan >> >> I am not afraid and I am also not afraid of being afraid. -- 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: pagetables used in interrupt context
Hi 卜弋天, > 2.6.35, i checked the function handle_level_irq()and handle_edge_irq() in > chip.c, both of them will call handle_IRQ_event() which is in handle.c. and > the function handle_IRQ_event() will call the interrupt handler written by > user. Kernel does not open interrupt(ARM CPSR I bit)when calling interrupt > handler in handle_IRQ_event() function. Thank you for the valuable pointers. I have looked at the handle_IRQ_event function, it seems at the end of the do while loop its unconditionally disable the local interrupt (ARM CPSR I bit). If the handler is running with interrupts disabled, why do we need to disable the interrupts again. Could you please explain about this logic. Thanks in advance for your help and sorry to take up your time 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
Re: pagetables used in interrupt context
Hi , > can support nest interrupt if it wants(2.6.35 does not support this). and it > is very simple to use the interrupted thread's kernel mode stack as the > interrupt context. if kernel use a specific stack which is for interrupt Thanks for the crystal clear explanation of the page table usage in interrupt context. I have one more doubt, so in 2.6.35 as you said it doesn't support nested interrupt, does it mean that all other interrupts are completely disabled, (I mean no other can interrupt the processor) while executing an interrupt handler. 2012/2/23 卜弋天 : > Hi : > > for ARM architecture, from the point of my view, interrupt can be > handled in IRQ, SVC, or SYSTEM modes. > 1.if kernel handles interrupt in IRQ mode, it can use separate specific > stack of IRQ mode to handle interrupt,but it cannot support nest interupt, > suppose you are running interrupt handler in IRQ mode, a new coming > interrupt will corrupt the lr_irq which is used for current function. > 2. if kernel handles interrupt in SYSTEM mode, the sequences will be : > hardware interrupt occurs-->IRQ mode-->SYSTEM mode -->call > interrupt handler. >kernel can support nest interrupt well by this way, the problem is > SYSTEM mode use the same register with USER mode, which means kernel will > use the interrupted thread's user mode stack, this will leake information > of kernel to user space, so it is not a good idea, although i did this for > many years for OMAP chipset(the OS is not linux, it is mixed by REX and my > own design.). > 3. Linux kernel choose the last one, handle interrupt in SVC mode, which > can support nest interrupt if it wants(2.6.35 does not support this). and it > is very simple to use the interrupted thread's kernel mode stack as the > interrupt context. if kernel use a specific stack which is for interrupt > only, the sequences will be : hardware interrupt occurs-->IRQ mode-->SVC > mode-->backup sp register of interrupted thread to it's TCB--->set sp > register to be the specific kernel stack address-->call interrupt > handler--->restore sp of interrupted thread--->return from interrupt. > this is a little complicated compared with the current design. so i > agree with the current design. > > > Best Regards > >> Date: Thu, 23 Feb 2012 08:41:28 -0600 > >> Subject: Re: pagetables used in interrupt context >> From: c.a.subraman...@gmail.com >> To: bu...@live.cn >> CC: dhyla...@gmail.com; subingangadha...@gmail.com; >> kernelnewbies@kernelnewbies.org > >> >> On Thu, Feb 23, 2012 at 6:52 AM, 卜弋天 wrote: >> > Hi Subin: >> > >> > for kernel version 2.6.35, ARM architecture, when interrupt occurs, >> > kernel will change from USER/SVC mode to IRQ mode,backup some registers >> > and >> > change to SVC mode immediately, handle the real interrupt handler in SVC >> > mode, which people say in interrupt context. >> > kernel will use the stack(interrupt context) of interrupted thread to >> > handle the interrupt, and there is no MMU operation which do page table >> > switch. >> > so the thread which is interrupted by interrupt, it's kernel mode stack >> > will be choosed as the interrupt context of current interrupt. >> > >> Thanks ! thats a terse explanation! Can you please mention why we do >> not have a IRQ stack (in terms of size of the stack) to do the >> processing? >> > >> >> Date: Tue, 21 Feb 2012 19:18:32 -0700 >> >> Subject: Re: pagetables used in interrupt context >> >> From: subingangadha...@gmail.com >> >> To: dhyla...@gmail.com >> >> CC: kernelnewbies@kernelnewbies.org >> > >> >> >> >> Thank you for clearing my doubt. >> >> >> >> On Mon, Feb 20, 2012 at 8:39 PM, Dave Hylands >> >> wrote: >> >> > Hi Subin, >> >> > >> >> > On Mon, Feb 20, 2012 at 6:47 PM, subin gangadharan >> >> > wrote: >> >> >> Hi All, >> >> >> >> >> >> Please correct me if I am wrong. In linux each process will have its >> >> >> own page tables, so when a interrupt happens processor will switch >> >> >> to >> >> >> interrupt context >> >> >> and execute the proper handler. So my doubt, if this is the case, >> >> >> interrupt hanlder will be using the pagetables of the interrupted >> >> >> process or is there a separate page table for this. >> >> > >> >> > Yep - that's right. Co
Re: pagetables used in interrupt context
Thank you for clearing my doubt. On Mon, Feb 20, 2012 at 8:39 PM, Dave Hylands wrote: > Hi Subin, > > On Mon, Feb 20, 2012 at 6:47 PM, subin gangadharan > wrote: >> Hi All, >> >> Please correct me if I am wrong. In linux each process will have its >> own page tables, so when a interrupt happens processor will switch to >> interrupt context >> and execute the proper handler. So my doubt, if this is the case, >> interrupt hanlder will be using the pagetables of the interrupted >> process or is there a separate page table for this. > > Yep - that's right. Conceptually you can imagine that the kernel page > tables are replicated in each process, so when the interrupt occurs, > the kernel mappings will always be in effect regardless of which task > is running. How this is actually achieved may vary from architecture > to architecture. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.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
pagetables used in interrupt context
Hi All, Please correct me if I am wrong. In linux each process will have its own page tables, so when a interrupt happens processor will switch to interrupt context and execute the proper handler. So my doubt, if this is the case, interrupt hanlder will be using the pagetables of the interrupted process or is there a separate page table for 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
Re: arm assembly doubt
Hi ,
Thanks alot for sharing the information.
2012/2/18 卜弋天 :
> Hi:
>
> the SWI is used for system APIs such as open, read, write. user mode
> applications call system APIs via SWI, which will change ARM mode from USER
> to SVC.
> so when vector_swi is called, Linux will do as below:
> 1. store r0~r12, these registers are universal for USR mode SVC mode.
> 2. store r13 and r14 of USER mode. Note, SWI is triggered from USER
> mode, so here Linux store USER mode's r13 and r14, rather than SVC's.
>
> for your two questions:
> 1. the ^ means to get USER mode registers, rather than current mode.
> 2. no matter how you arrange registers in opcode {}, stmdb will always
> push lr first, then sp. so after line 348, the stack view is as below:
> lr_usr
> sp_usr
> r12
> ...
> r0
This is where I really got confused,I was thinking sp will be pushed
first in that case stack view will be completely different. However
the system is working fine,so was sure there is some secret behind
this instruction.Thanks for revealing this mystery.
>
>> Date: Thu, 16 Feb 2012 19:35:17 -0700
>> Subject: Re: arm assembly doubt
>> From: subingangadha...@gmail.com
>> To: su...@gatech.edu
>> CC: kernelnewbies@kernelnewbies.org
>
>>
>> Thanks for the answer. Actually this is what I am trying to understand.
>>
>> ENTRY(vector_swi)
>> 345 sub sp, sp, #S_FRAME_SIZE
>> 346 stmia sp, {r0 - r12} @ Calling r0 - r12
>> 347 ARM( add r8, sp, #S_PC )
>> 348 ARM( stmdb r8, {sp, lr}^ ) @ Calling sp, lr
>> 349 THUMB( mov r8, sp )
>> 350 THUMB( store_user_sp_lr r8, r10, S_SP ) @ calling sp, lr
>> 351 mrs r8, spsr @ called from
>> non-FIQ mode, so ok.
>> 352 str lr, [sp, #S_PC] @ Save calling PC
>> 353 str r8, [sp, #S_PSR] @ Save CPSR
>> 354 str r0, [sp, #S_OLD_R0]
>>
>> In this case after the line number 348(if its in arm mode),will the
>> kernel stack have the contents
>> r0-r12,sp,lr in this order or r0-r12,lr,sp this one. Beccause I
>> believe stmdb r8, {sp, lr}^ will push the sp first then lr. In that
>> case sp and lr will be interchanged in struct pt_regs.
>>
>> Please correct me if I am wrong.
>>
>>
>>
>>
>>
>> On Wed, Feb 15, 2012 at 9:34 PM, Surenkumar Nihalani
>> wrote:
>> > Hi,
>> > On Feb 15, 2012, at 11:30 PM, subin gangadharan wrote:
>> >
>> >> Hi ,
>> >>
>> >> I am trying to understand how system call is implmented in linux for
>> >> arm.And I am not that familiar with arm assembly.
>> >>
>> >> Could any body please help me to understand what exactly this ^ does
>> >> in this instruction stmdb r8,{sp,lr}^
>> >>
>> >> --
>> >> 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
>> >
>> > Example:
>> >LDFMD sp!, {r0-r12, pc}^
>> > - The ^ qualifier specifies that the CPSR is restored from the SPSR.
>> > It must be used only from a privileged mode.
>> >
>>
>>
>>
>> --
>> 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
--
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: arm assembly doubt
Thanks for the answer. Actually this is what I am trying to understand.
ENTRY(vector_swi)
345 sub sp, sp, #S_FRAME_SIZE
346 stmia sp, {r0 - r12} @ Calling r0 - r12
347 ARM( add r8, sp, #S_PC )
348 ARM( stmdb r8, {sp, lr}^ ) @ Calling sp, lr
349 THUMB( mov r8, sp )
350 THUMB( store_user_sp_lr r8, r10, S_SP ) @ calling sp, lr
351 mrs r8, spsr@ called from
non-FIQ mode, so ok.
352 str lr, [sp, #S_PC] @ Save calling PC
353 str r8, [sp, #S_PSR]@ Save CPSR
354 str r0, [sp, #S_OLD_R0]
In this case after the line number 348(if its in arm mode),will the
kernel stack have the contents
r0-r12,sp,lr in this order or r0-r12,lr,sp this one. Beccause I
believe stmdb r8, {sp, lr}^ will push the sp first then lr. In that
case sp and lr will be interchanged in struct pt_regs.
Please correct me if I am wrong.
On Wed, Feb 15, 2012 at 9:34 PM, Surenkumar Nihalani wrote:
> Hi,
> On Feb 15, 2012, at 11:30 PM, subin gangadharan wrote:
>
>> Hi ,
>>
>> I am trying to understand how system call is implmented in linux for
>> arm.And I am not that familiar with arm assembly.
>>
>> Could any body please help me to understand what exactly this ^ does
>> in this instruction stmdb r8,{sp,lr}^
>>
>> --
>> 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
>
> Example:
> LDFMD sp!, {r0-r12, pc}^
> - The ^ qualifier specifies that the CPSR is restored from the SPSR.
> It must be used only from a privileged mode.
>
--
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
arm assembly doubt
Hi ,
I am trying to understand how system call is implmented in linux for
arm.And I am not that familiar with arm assembly.
Could any body please help me to understand what exactly this ^ does
in this instruction stmdb r8,{sp,lr}^
--
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: interrupt handler in arm question
Thanks Kosta,
I have looked at the code,but it seems 3.0 is slightly different.
Anyway your pointers will help me to understanding it better.
On Tue, Dec 13, 2011 at 6:52 AM, Konstantin Zertsekel
wrote:
>> I have one more question.I have searched in the source code,but
>> couldn't figure it out.
>> As you mentioned earlier,running ISR in SVC is mainly to make it re
>> entrant,but where
>> its getting enabled again(interrupt) after ARM has been disabled it
>> when an interrupt happens.
>> Could you please give an idea on this.
>
> Please take a look at handle_IRQ_event in kernel/irq/handle.c:
>
> irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
> {
> irqreturn_t ret, retval = IRQ_NONE;
> unsigned int status = 0;
>
> if (!(action->flags & IRQF_DISABLED))
> local_irq_enable_in_hardirq(); <--- !
>
> ...
> }
>
> It is called from kernel/irq/chip.c file for every type of IRQ
> interrupt (simple IRQ, level IRQ, enge IRQ and percpu IRQ).
>
> Now, local_irq_enable_in_hardirq is defined in inlude/linux/interrupt.h:
>
> #ifdef CONFIG_LOCKDEP
> # define local_irq_enable_in_hardirq() do { } while (0)
> #else
> # define local_irq_enable_in_hardirq() local_irq_enable()
> #endif
>
> Now, local_irq_enable is defined in include/linux/irqflags.h:
>
> #define local_irq_enable() \
> do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0)
> And, at last, raw_local_irq_enable is defined in
> arch/arm/include/asm/irqflags.h:
>
> #define raw_local_irq_enable() \
> ({ \
> unsigned long temp; \
> __asm__ __volatile__( \
> "mrs %0, cpsr @ local_irq_enable\n" \
> " bic %0, %0, #128\n" \
> " msr cpsr_c, %0" \
> : "=r" (temp) \
> : \
> : "memory", "cc"); \
> })
>
> This last macro essentially clears the I (big i) bit in CPSR register
> - this enables IRQ exceptions.
>
> Hope, it helps.
> --- Kosta
--
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 Mulyadi, Thanks for the answer. On Mon, Dec 12, 2011 at 11:16 AM, Mulyadi Santosa wrote: > Hi... > > On Mon, Dec 12, 2011 at 01:11, subin gangadharan > 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: interrupt handler in arm question
Hi Kosta, I have one more question.I have searched in the source code,but couldn't figure it out. As you mentioned earlier,running ISR in SVC is mainly to make it re entrant,but where its getting enabled again(interrupt) after ARM has been disabled it when an interrupt happens. Could you please give an idea on this. With Regards, Subin K G On Mon, Dec 12, 2011 at 2:23 AM, Konstantin Zertsekel wrote: >>> FIQ exception is not implemented in Linux Kernel. >>> Actually, when ARM CPU takes FIQ exception, it branches to 0x001c >>> address, which contains the below code from entry-armv.S: >>> vector_fiq: >>> disable_fiq >>> subs pc, lr, #4 >>> >>> Now, disable_fiq not implemented for all the platforms. >>> But, anyway, 'subs pc, lr, #4' returns the CPU to the point where >>> FIQ exception has happened and the system continues to run as usual. >> >> As you said, disable_fiq is empty in OMAP architecture. >> .macro disable_fiq >> .endm >> >> So from the above explanation,I can saythat LINUX is not making use of >> FIQ feature of arm.Am I right? > > Absolutely. --- Kosta -- 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 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
Re: interrupt handler in arm question
Hi Kosta, Thanks for answering.I really appreciate you taking the time to answer my question. On Sun, Dec 11, 2011 at 10:07 AM, Konstantin Zertsekel wrote: >> 2) In case of FIQ mode to which routine it jumps to,basically in IRQ >> mode it jumps to either __irq_svc or __irq_usr as you explained >> earlier. >> I have looked at the source code, but I couldn't figure out in >> case of FIQ, where its branching to. > > That's for a good reason :-) > FIQ exception is not implemented in Linux Kernel. > Actually, when ARM CPU takes FIQ exception, it branches to 0x001c > address, which contains the below code from entry-armv.S: > vector_fiq: > disable_fiq > subs pc, lr, #4 > > Now, disable_fiq not implemented for all the platforms. > But, anyway, 'subs pc, lr, #4' returns the CPU to the point where > FIQ exception has happened and the system continues to run as usual. As you said, disable_fiq is empty in OMAP architecture. .macro disable_fiq .endm So from the above explanation,I can saythat LINUX is not making use of FIQ feature of arm.Am I right? > >>>> I am trying to understand how the interrupt handler in arm working.By >>>> looking at the code,what I understood,when an interrupt >>>> happens arm disables the irq, saves the cpsr to spsr,save current pc >>>> to lr and switches to irq mode. >>> >>> Yes, that's right. >>> Important to understand that IRQ processor mode has its (mode-private) >>> own sp, lr and spsr registers. >>> Additionally, mode-private registers (sp, lr and spsr) are >>> inaccessible from other modes. > >>>> So in case of interrupt it branches to the vector_irq and there it >>>> saves some registers and depending on which context >>>> its happened,it will call __irq_user or __irq_svc. But before that it >>>> switches to the supervisory mode. > >>> That's right. In Linux Kernel the IRQ, Data Abort, Prefetch Abort, SWI >>> and Undefined exceptions >>> are handled in SVC processor mode. In Linux SVC processor mode of ARM >>> CPU is called "Kernel mode". >>> You have to switch to SVC processor mode from IRQ (and other processor >>> modes) to enabled reentrant >>> interrupts. >>> Simplistically, it works like this: (1) IRQ exception is entered, (2) >>> spsr_irq, r0 and lr_irq is saved >>> on the private IRQ stack (its size is only 12 bytes), (3) >>> 'vector_stub' macro check from what >>> processor mode we got here - kernel mode or user mode - and calculates >>> what to call __irq_user >>> or__irq_svc and (4) the last thing it does 'movs pc, lr' which loads >>> spsr_irq into cpsr and puts lr >>> into pc (lr now contains __irq_svc or __irq_user and spsr_irq[4:0] >>> contains SVC mode bits). >>> Mind, that r0 points to private IRQ stack that contains original r0, >>> lr_irq and spsr_irq. > >> 1) Does the LINUX handles the interrupt like this in all other >> architectures.I mean handler will always be executed in SVC mode. > > Sorry, I am too unfamiliar with other architectures... to my detriment > actually. > Can anybody fill the knowledge gap here?! > > --- Kosta -- 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: interrupt handler in arm question
Hi Kosta, Thank you very much for information.I have two more questions related to this one. 1) Does the LINUX handles the interrupt like this in all other architectures.I mean handler will always be executed in SVC mode. 2) In case of FIQ mode to which routine it jumps to,basically in IRQ mode it jumps to either __irq_svc or __irq_usr as you explained earlier. I have looked at the source code, but I couldn't figure out in case of FIQ, where itsbranching to. Could you please give me a bit more explanation on this. Thanks in advance. On Sun, Dec 11, 2011 at 7:00 AM, Konstantin Zertsekel wrote: >> I am trying to understand how the interrupt handler in arm working.By >> looking at the code,what I understood,when an interrupt >> happens arm disables the irq, saves the cpsr to spsr,save current pc >> to lr and switches to irq mode. > > Yes, that's right. > Important to understand that IRQ processor mode has its (mode-private) > own sp, lr and spsr registers. > Additionally, mode-private registers (sp, lr and spsr) are > inaccessible from other modes. > >> So in case of interrupt it branches to the vector_irq and there it >> saves some registers and depending on which context >> its happened,it will call __irq_user or __irq_svc. But before that it >> switches to the supervisory mode. > > That's right. In Linux Kernel the IRQ, Data Abort, Prefetch Abort, SWI > and Undefined exceptions > are handled in SVC processor mode. In Linux SVC processor mode of ARM > CPU is called "Kernel mode". > You have to switch to SVC processor mode from IRQ (and other processor > modes) to enabled reentrant > interrupts. > Simplistically, it works like this: (1) IRQ exception is entered, (2) > spsr_irq, r0 and lr_irq is saved > on the private IRQ stack (its size is only 12 bytes), (3) > 'vector_stub' macro check from what > processor mode we got here - kernel mode or user mode - and calculates > what to call __irq_user > or__irq_svc and (4) the last thing it does 'movs pc, lr' which loads > spsr_irq into cpsr and puts lr > into pc (lr now contains __irq_svc or __irq_user and spsr_irq[4:0] > contains SVC mode bits). > Mind, that r0 points to private IRQ stack that contains original r0, > lr_irq and spsr_irq. > >> Here I got confused,because in this case user registered handler will >> be executed in supervisory mode. >> I was thinking interrupt handler will always be executed in interrupt mode. > > As said above, interrupt handler is executed in kernel mode. > This is must to support reentrant interrupts. > > --- Kosta -- 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
interrupt handler in arm question
Hi All, I am trying to understand how the interrupt handler in arm working.By looking at the code,what I understood,when an interrupt happens arm disables the irq, saves the cpsr to spsr,save current pc to lr and switches to irq mode. So in case of interrupt it branches to the vector_irq and there it saves some registers and depending on which context its happened,it will call __irq_user or __irq_svc.But before that it switches to the supervisory mode. Here I got confused,because in this case user registered handler will be executed in supervisory mode. I was thinking interrupt handler will always be executed in interrupt mode. Could any one please give some pointers 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
Re: task switching and current pointer implemenation question
Hi Dave, Thanks a lot for your crystal clear explanation of my question. Now I understood, actually I was thinking there will be only one stack in kernel space which will be shared by all apps. Thanks again. On Sat, Dec 10, 2011 at 1:00 PM, Dave Hylands wrote: > Hi Subin, > > On Sat, Dec 10, 2011 at 7:35 AM, subin gangadharan > wrote: >> >> Hi Guys, >> >> I have a question related to task switching.Basically when user space >> application switches to kernel (through sys calls), >> which stack will be used for the user app.Mainly I want to know how >> the current pointer implementation works. >> I saw that in arm they are masking the sp with ~(THREAD_SIZE -1) and >> getting the current thread info and from there its >> taking the task pointer. >> >> So here I am a little confused about the stack pointer since when it >> switches the kernel it will be supervisory mode,so which >> sp it's referencing.I know it will be a supervisory stack,but how this >> stack will be related with the user app. > > > Every thread gets a kernel stack (typically of around 8K, although this can > vary by config options and architecture). This stack is created when the > thread is created. Whenever the code transitions from kernel space into user > space, the kernel sp is saved and the user sp is restored. When calling from > user-space into kernel space, the user-sp is saved and the kernel-sp is > restored. > > Each thread has some thread-info which is stored on the low end of the > stack. Since the stacks are 8K is size and 8K aligned (or some other power > of 2 in size and the same power of 2 aligned), you can do a simple masking > operation with the sp to retrieve the thread-info. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.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
task switching and current pointer implemenation question
Hi Guys, I have a question related to task switching.Basically when user space application switches to kernel (through sys calls), which stack will be used for the user app.Mainly I want to know how the current pointer implementation works. I saw that in arm they are masking the sp with ~(THREAD_SIZE -1) and getting the current thread info and from there its taking the task pointer. So here I am a little confused about the stack pointer since when it switches the kernel it will be supervisory mode,so which sp it's referencing.I know it will be a supervisory stack,but how this stack will be related with the user app. If anybody could give a pointer on this,it would be of great help to me. -- 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
Question on __pv_stub
Hi All, I am just trying to understand __va macro. I can see two definitions,one in include/asm-generic/page.h and other is in arch/arm/include/asm/memory.h. The first definition is just adding PAGE_OFFSET,but the second one boil downs to __pv_stub.Could anybody please help me to understand what this __pv_stub for? With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Can i allocate 4GB virtual addresses (more than a certain limit) using vmalloc?
Hi Dave, >Also keep in mind that when you vmalloc stuff you're allocating in >units of pages, and there is a guard page between each allocation. So >if you had 512 Mb of virtual space (which is 131,072 pages), you'll be >able to vmalloc a maximum of 65536 objects or 1 page each. Fewer >objects if they're bigger than a page. A quick question, Suppose if I alloc 1MB of memory using vmalloc,Is there a guard page between each page or is it after the 1MB. With Regards, Subin K G On Tue, May 31, 2011 at 10:19 AM, Dave Hylands wrote: > Hi Sandeep, > > On Mon, May 30, 2011 at 10:54 PM, sandeep kumar > wrote: > > Hi all, > > The following link gives the memory map for the arm architecture. > > http://www.arm.linux.org.uk/developer/memory.txt > > > > I have the following doubts.. > > 1) Any chipset(based on arm) manufacturer(qualcom,samsung..) should > follow > > the same memory map. > > Is it hardly constrained or can be changed? > > Where are this constraints are implemented in the kernel source tree? > > You can have 2 different configurations for the same chip which > present totally different memory maps. Where things are physically in > memory varies from chip to chip, regardless of the fact that they > happen to use the same processor. > > > 2) while i was student, i read in OS concepts that, "Virtual memory > gives an > > illusion to a process, > > that it has always a larger continuous address space (even more than RAM) > > available to it." > > So i thought i could allocate howmuch ever memory i want. > > But seeing the above link,i observed there is some limitation in the > address > > space created by the vmalloc(). > > So i m now thinking that vmalloc has some limit. > > Absolutely. You can only vmalloc as much memory as there is virtual > space reserved for vmalloc. And your vmalloc memory space can become > fragmented, so you could have lots of space, but not have enough > contiguous virtual space left to allocate a large object. > > Also keep in mind that when you vmalloc stuff you're allocating in > units of pages, and there is a guard page between each allocation. So > if you had 512 Mb of virtual space (which is 131,072 pages), you'll be > able to vmalloc a maximum of 65536 objects or 1 page each. Fewer > objects if they're bigger than a page. > > The actual allocation of vmalloc memory is determined by the macros > VMALLOC_START and VMALLOC_END. VMALLOC_START is defined in > arch/arm/include/asm/pgtable.h: > http://lxr.linux.no/linux+v2.6.39/arch/arm/include/asm/pgtable.h#L41 > although it can be overriden by a particular architecture. > > VMALLOC_END is normally defined in the machine's memory.h file, and it > sits somewhere between VMALLOC_START and the beginning of I/O space. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.com > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to get the physical address of memory allocated by kmalloc
Hi All, Is there any API exists in kernel to get the physical address of the memory allocated by kmalloc.Can I use virt_to_phys for this ? With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: xx_initcall ( ) in kernel
On Wed, Jul 13, 2011 at 4:09 AM, nilesh wrote: > Hi Sumeet, > > On Wednesday 13 July 2011 04:12 PM, sumeet linux wrote: > > Dear friends, > > > > I want to know the basics xx_initcall ( ) in linux kernel. How this > function > > works ? > > Observed in kernel code, many places late_initcall ( ), early_initcall ( > ), > > arch_initcall ( ), core_initcall ( ) gets called. > > When did all these functions gets call during kernel initialization ? > > I am more interested in what is the sequence of these functions gets > called > > one after another. > I could get a nice link explaining about *_initcall(). Refer: > > http://book.opensourceproject.org.cn/embedded/embeddedprime/opensource/0136130550/ch05lev1sec4.html > > *_initcall() are macros which set the function pointers for subsystem > initialization (typedef int (*initcall_t)(void) : typedef of all such > function pointers). > Also if we look at the source code, the functions are called in below > sequence: > http://lxr.linux.no/#linux+v2.6.39/init/main.c#L695 > > do_basic_setup(void) -> do_initcalls(void) -> do_one_initcall(*fn); > do_one_initcall(*fn) - calls each function. And do_basic_setup() is > called inside the initialization sequence (kernel_init()). > > > > > Thank you. > > > > Regards, > > Sumeet > > > > -- > Thanks, > Nilesh > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Hi, I hope this will help you to get a basic understanding of init call. http://www.embedded-bits.co.uk/2008/init-call-mechanism/ -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question on Alignment requiremnet
On Sun, Aug 7, 2011 at 5:22 AM, Greg Freemyer wrote: > > On Aug 6, 2011 1:57 PM, "Mulyadi Santosa" > wrote: > > > > On Sat, Aug 6, 2011 at 23:59, subin gangadharan > > wrote: > > > Hi All, > > > I have some doubts on the alignment requirement.It would be really > > > helpful,if someone can shed some light on this. > > > Why there are so many different types of alignment like 4 byte, 8 > byte,16 > > > byte ?.My exact question is, in a 32 bit machine(I assume processor > reads > > > data in 4 bytes),how 16 byte alignment makes different from 4 byte > alignment > > > ?.How this will influence the processor performance ?. > > > > personal guess: cache line alignment? > > > > ... so the data all can be read in one read swipe. > > > > or in other hand, if several data has different access type (some are > > read only, the rest are read/write), then by aligning them to > > different cache line, they won't interfere to each other...since AFAIK > > a write to even one bit in a cache line will update the whole cache > > line. Other data in the same cache line will stay, they will be just > > rewritten AFAIK. > > > > I hope my guess is right :) > > Too complex I think. Don't try to think so hard. ;-) > > Most cpu's offer an atomic test_and_set instruction. > > It is used to write busy loop semaphore code like. > > While (test_and_set(flag) == false); > # coded in assembly > > Normally that busy loops until flag initially has a value of zero during > the test and the test changes it to a one. > > But if test_and_set always fails due lack of alignment, that loop will > never finish. > > Greg > Thank you guys for helping me to clear out the doubts. -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: One more question on alignment
On Sat, Aug 6, 2011 at 12:37 PM, Daniel Baluta wrote: > On Sat, Aug 6, 2011 at 10:17 PM, subin gangadharan > wrote: > > Hi, > > This is a text excerpt from the article [1]. > > Below paragraph I didn't understand quite well.Mainly in bold > letters.Could > > anybody please explain how this will lead to an infinite loop. > > It seems self-explanatory. Most atomic ops are written to retry upon a > failed > store, and on PowerPC an atomic store to an unaligned address always > fails, > thus the processor will infinitely try to store the value, without having > the chance to fix the unaligned access (as would have happened if an > exception > was thrown). > > > > > Unfortunately, the PowerPC does not throw an exception when atomically > > storing to an unaligned address. Instead, the store simply always fails. > > This is bad because most atomic functions are written to retry upon a > failed > > store, under the assumption they were preempted. These two circumstances > > combine to where your program will go into an infinite loop if you > attempt > > to atomically store to an unaligned address. Oops. > > thanks, > Daniel. > Thanks Daniel, My bad, I was trying to connect the page fault explained before that paragraph and this one. Hence I got confused,again thanks for clarifying it. -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
One more question on alignment
Hi, This is a text excerpt from the article [1]. Below paragraph I didn't understand quite well.Mainly in bold letters.Could anybody please explain how this will lead to an infinite loop. Atomicity All modern processors offer atomic instructions. These special instructions are crucial for synchronizing two or more concurrent tasks. As the name implies, atomic instructions must be *indivisible* -- that's why they're so handy for synchronization: they can't be preempted. It turns out that in order for atomic instructions to perform correctly, the addresses you pass them must be at least four-byte aligned. This is because of a subtle interaction between atomic instructions and virtual memory. If an address is unaligned, it requires at least two memory accesses. But what happens if the desired data spans two pages of virtual memory? This could lead to a situation where the first page is resident while the last page is not. Upon access, in the middle of the instruction, a page fault would be generated, executing the virtual memory management swap-in code, destroying the atomicity of the instruction. To keep things simple and correct, both the 68K and PowerPC require that atomically manipulated addresses always be at least four-byte aligned. *Unfortunately, the PowerPC does not throw an exception when atomically storing to an unaligned address. Instead, the store simply always fails. This is bad because most atomic functions are written to retry upon a failed store, under the assumption they were preempted. These two circumstances combine to where your program will go into an infinite loop if you attempt to atomically store to an unaligned address. Oops.* [1] http://www.ibm.com/developerworks/library/pa-dalign/. -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question on Alignment requiremnet
On Sat, Aug 6, 2011 at 10:56 AM, Mulyadi Santosa wrote: > On Sat, Aug 6, 2011 at 23:59, subin gangadharan > wrote: > > Hi All, > > I have some doubts on the alignment requirement.It would be really > > helpful,if someone can shed some light on this. > > Why there are so many different types of alignment like 4 byte, 8 byte,16 > > byte ?.My exact question is, in a 32 bit machine(I assume processor reads > > data in 4 bytes),how 16 byte alignment makes different from 4 byte > alignment > > ?.How this will influence the processor performance ?. > > personal guess: cache line alignment? > > ... so the data all can be read in one read swipe. > > or in other hand, if several data has different access type (some are > read only, the rest are read/write), then by aligning them to > different cache line, they won't interfere to each other...since AFAIK > a write to even one bit in a cache line will update the whole cache > line. Other data in the same cache line will stay, they will be just > rewritten AFAIK. > > I hope my guess is right :) > Thanks for your quick reply.I have one more question. So in case of processor with read/write granularity of 4 byte access,just for understanding purpose imagine it's with out cache.So in that case any difference is there between 4byte and other 8byte,16 byte alignment. > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question on Alignment requiremnet
Hi All, I have some doubts on the alignment requirement.It would be really helpful,if someone can shed some light on this. Why there are so many different types of alignment like 4 byte, 8 byte,16 byte ?.My exact question is, in a 32 bit machine(I assume processor reads data in 4 bytes),how 16 byte alignment makes different from 4 byte alignment ?.How this will influence the processor performance ?. - With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Some doubts on MUTEX
On Wed, Feb 23, 2011 at 2:04 AM, Dave Hylands wrote: > Hi Subin, > > On Tue, Feb 22, 2011 at 8:58 PM, subin gangadharan > wrote: > > > > > > On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands > wrote: > >> > >> Hi Subin, > >> > >> On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan > >> wrote: > >> > Hi All, > >> > I am trying to understand how to use mutex API's properly,so while > going > >> > through the documentation, > >> > there is section mentioning fast path and slow path for mutexes. > >> > For your reference I am pasting this here.(kernel/mutex.c) > >> > /* > >> > * We split the mutex lock/unlock logic into separate fastpath and > >> > * slowpath functions, to reduce the register pressure on the > fastpath. > >> > * We also put the fastpath first in the kernel image, to make sure > the > >> > * branch is predicted by the CPU as default-untaken. > >> > */ > >> > static __used noinline void __sched > >> > __mutex_lock_slowpath(atomic_t *lock_count); > >> > > >> > Can someone help me to understand what is the difference between > >> > fastpath > >> > lock and slowpath lock? > >> > >> The fastpath is taken when nobody else is holding the lock (so the > >> caller acquires the mutex without blocking). > >> > >> The slowpath is taken when somebody else is holding the lock and the > >> caller needs to block (i.e. sleep) until the mutex is released. > >> > > Thanks David. > > Could you give a bit more idea on the "How this reduce the register > pressure > > on fast path" > > The code for the slowpath is considerably more complex than the code > for the fastpath. So the fastpath will need much fewer registers. > Since the compiler needs to generate save/restore operations for many > touched registers, by having the slow path in a separate function, the > extra save/restores are only done if they're needed. > > The fastpath does the minimal amount required, so fewer registers will > be required and less saving/restoring needs to be done. > > Dave Hylands > Hi David, Now I got it.Thanks again for your time and the clear explanation you gave me. -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Some doubts on MUTEX
On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands wrote: > Hi Subin, > > On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan > wrote: > > Hi All, > > I am trying to understand how to use mutex API's properly,so while going > > through the documentation, > > there is section mentioning fast path and slow path for mutexes. > > For your reference I am pasting this here.(kernel/mutex.c) > > /* > > * We split the mutex lock/unlock logic into separate fastpath and > > * slowpath functions, to reduce the register pressure on the fastpath. > > * We also put the fastpath first in the kernel image, to make sure the > > * branch is predicted by the CPU as default-untaken. > > */ > > static __used noinline void __sched > > __mutex_lock_slowpath(atomic_t *lock_count); > > > > Can someone help me to understand what is the difference between fastpath > > lock and slowpath lock? > > The fastpath is taken when nobody else is holding the lock (so the > caller acquires the mutex without blocking). > > The slowpath is taken when somebody else is holding the lock and the > caller needs to block (i.e. sleep) until the mutex is released. > > Thanks David. Could you give a bit more idea on the "How this reduce the register pressure on fast path" > Dave Hyland > -- With Regards Subin Gangadharan Everything should be made as simple as possible,but not simpler. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Some doubts on MUTEX
Hi All, I am trying to understand how to use mutex API's properly,so while going through the documentation, there is section mentioning fast path and slow path for mutexes. For your reference I am pasting this here.(kernel/mutex.c) /* * We split the mutex lock/unlock logic into separate fastpath and * slowpath functions, to reduce the register pressure on the fastpath. * We also put the fastpath first in the kernel image, to make sure the * branch is predicted by the CPU as default-untaken. */ static __used noinline void __sched __mutex_lock_slowpath(atomic_t *lock_count); Can someone help me to understand what is the difference between fastpath lock and slowpath lock? Thanks in advance Subin Gangadharan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
