Re: Ordering / preemption of work in a workqueue preempt?
On Mon, Nov 18, 2013 at 10:20 PM, Arun KS wrote:
> Hi Rajat,
>
> On Fri, Nov 15, 2013 at 8:46 PM, Rajat Jain wrote:
>> Hi,
>>
>> I have a single work queue, on which I have scheduled a worker function
>> [using queue_work(wq, fn)] in interrupt context.
>>
>> I get the interrupt twice before the work queue gets a chance to run, and
>> hence the same function will get queued twice (with different private
>> context - arguments etc) which is fine and expected.
>
> You got it wrong here.
>
> bool queue_work_on(int cpu, struct workqueue_struct *wq,
>struct work_struct *work)
> {
> bool ret = false;
> unsigned long flags;
>
> local_irq_save(flags);
>
> if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work)))
> {
> __queue_work(cpu, wq, work);
> ret = true;
> }
>
> local_irq_restore(flags);
> return ret;
> }
> EXPORT_SYMBOL(queue_work_on);
>
> If you look at function queue_work_on, the function returns
> immediately if WORK_STRUCT_PENDING_BIT was already set.
> So in effect your second call to queue_work will just return.
Best thing to do is just disable interrupt as soon as you receive
first interrupt
and re-enable it when you think you can handle it.I hope you are not writing
network driver where this sequence would cause unacceptable delays.
>
> HTH
>
> Thanks,
> Arun
>
>
>>
>> Questions:
>>
>> 1) Is it possible that the instance that was queued by 2nd interrupt, can
>> get to run BEFORE the instance that was queued by 1st interrupt? In other
>> words, is reordering possible?
>>
>> 2) Is it possible that one running instance of the function, can get
>> preempted by second instance of the same work queue? I read through
>> http://lwn.net/Articles/511421/ and it talks about same work queue cannot
>> run on different CPU, but I have doubt about single CPU. If If I am writing
>> a worker function, does my code have to be ready that it can be preempted by
>> another instance of the same function?
>>
>> Please note that I understand that my worker function can preempted by other
>> processes, my doubts are related to the same workqueue.
>>
>> Thanks,
>>
>> Rajat
>>
>>
>> ___
>> 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: Ordering / preemption of work in a workqueue preempt?
Hi Rajat,
On Fri, Nov 15, 2013 at 8:46 PM, Rajat Jain wrote:
> Hi,
>
> I have a single work queue, on which I have scheduled a worker function
> [using queue_work(wq, fn)] in interrupt context.
>
> I get the interrupt twice before the work queue gets a chance to run, and
> hence the same function will get queued twice (with different private context
> - arguments etc) which is fine and expected.
You got it wrong here.
bool queue_work_on(int cpu, struct workqueue_struct *wq,
struct work_struct *work)
{
bool ret = false;
unsigned long flags;
local_irq_save(flags);
if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work))) {
__queue_work(cpu, wq, work);
ret = true;
}
local_irq_restore(flags);
return ret;
}
EXPORT_SYMBOL(queue_work_on);
If you look at function queue_work_on, the function returns
immediately if WORK_STRUCT_PENDING_BIT was already set.
So in effect your second call to queue_work will just return.
HTH
Thanks,
Arun
>
> Questions:
>
> 1) Is it possible that the instance that was queued by 2nd interrupt, can get
> to run BEFORE the instance that was queued by 1st interrupt? In other words,
> is reordering possible?
>
> 2) Is it possible that one running instance of the function, can get
> preempted by second instance of the same work queue? I read through
> http://lwn.net/Articles/511421/ and it talks about same work queue cannot run
> on different CPU, but I have doubt about single CPU. If If I am writing a
> worker function, does my code have to be ready that it can be preempted by
> another instance of the same function?
>
> Please note that I understand that my worker function can preempted by other
> processes, my doubts are related to the same workqueue.
>
> Thanks,
>
> Rajat
>
>
> ___
> 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: Updating the kernel
Yes, Ksplice offers this feature. Though check with them if your specific distro is supported. Or if you're compiling your own kernel then I guess you'll have to send them the new image which they convert to a reboot-less image which can be applied to a running system. -mandeep On Tue, Nov 19, 2013 at 10:55 AM, Shraddha Kamat wrote: > Is it possible to keep the kernel updated to upstream without ever > rebooting the system ? Ksplice ?? > > Regards, > Shraddha > > > ___ > 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
Updating the kernel
Is it possible to keep the kernel updated to upstream without ever rebooting the system ? Ksplice ?? Regards, Shraddha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Embedded Toolchain
Hi Anuz, Thanks for your inputs. -Anand Moon On Monday, November 18, 2013 9:23 PM, Anuz Pratap Singh Tomar wrote: On Mon, Nov 18, 2013 at 4:52 AM, Anand Moon wrote: Hi All, > > >During compilation of openwrt it obviously create an embedded tookchain using >the gcc, buildutils >and the kernel for architecture i.e. (MIPS or ARM). >So is it that this toolchain will work for that particular architecture board >only and for that particular kernel. > > Particular board only: depends. Particular arch only: mostly. Arm toolchain will not work for PPC or MIPS and vice versa. Can this new toolchain replace the old toolchain for embedded boards of same architecture i.e. MIPS or ARM. > > Likely, the cross compile toolchains can have a lot of compatabilty issues. Which toolchain works with which arch and which version and which model are highly specific to the type of toolchain and board in question. Please share your thoughts on this. > > >-Anand Moon > >___ >Kernelnewbies mailing list >Kernelnewbies@kernelnewbies.org >http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Thank you Warm Regards Anuz ___ 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: Embedded Toolchain
On Mon, Nov 18, 2013 at 4:52 AM, Anand Moon wrote: > Hi All, > > During compilation of openwrt it obviously create an embedded > tookchain using the gcc, buildutils > and the kernel for architecture i.e. (MIPS or ARM). > So is it that this toolchain will work for that particular architecture > board only and for that particular kernel. > > Particular board only: depends. Particular arch only: mostly. Arm toolchain will not work for PPC or MIPS and vice versa. > Can this new toolchain replace the old toolchain for embedded boards of > same architecture i.e. MIPS or ARM. > > Likely, the cross compile toolchains can have a lot of compatabilty issues. Which toolchain works with which arch and which version and which model are highly specific to the type of toolchain and board in question. > Please share your thoughts on this. > > -Anand Moon > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Thank you Warm Regards Anuz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
