Khelper is a workqueue thread which has PF_NO_SETAFFINITY set.
When a usermode process is spawned by khelper through __call_usermodehelper()
which will invoke kernel_thread() (not kthread_create()) to fork the new
process, we will clearly see that it will inherit the PF_NO_SETAFFINITY flag.
Conse
Userspace process doesn't want the PF_NO_SETAFFINITY, but its parent may be
a kernel worker thread which has PF_NO_SETAFFINITY set, and this worker thread
can do kernel_thread() to create the child.
Clearing this flag in usersapce child to enable its migrating capability.
Signed-off-by: Zhang Yi
Userspace process doesn't want the PF_NO_SETAFFINITY, but its parent may be
a kernel worker thread which has PF_NO_SETAFFINITY set.
Clearing this flag in usersapce child to enable its migrating capability.
Signed-off-by: Zhang Yi
--- linux-3.12.old/fs/exec.c2013-11-26 08:53:12.175811856 +00
The kernel worker thread has the PF_NO_SETAFFINITY flag, and it is propagated
into the userspace child. Clearing this flag in usersapce child to enable its
migrating capability.
Signed-off-by: Zhang Yi
--- linux3-12/kernel/kmod.c 2013-11-14 09:06:58.991781656 +
+++ linux3-12/kernel/kmo
Zhang Yi wrote on 2013/10/08 13:59:36:
> Re: Re: Re: [PATCH] futex: Remove the owner check when waking task in
> handle_futex_death
>
> Darren Hart wrote on 2013/09/27 23:32:27:
> >
> > Re: Re: [PATCH] futex: Remove the owner check when waking task in
> > handle_futex_death
> >
> > >
> > >
Darren Hart wrote on 2013/09/27 23:32:27:
>
> Re: Re: [PATCH] futex: Remove the owner check when waking task in
> handle_futex_death
>
> >
> > The earlier patch cannot solve another problem:
> > The owner wakes the next waiter through normal unlocking which make the
> > futex value as zero, th
Darren Hart wrote on 2013/09/27 02:15:17:
> Re: [PATCH] futex: Remove the owner check when waking task in
> handle_futex_death
>
> On Thu, 2013-09-26 at 09:09 +0800, zhang.y...@zte.com.cn wrote:
> > Hi all,
> >
> > Task processes all its owned robust futex when it is exiting,
> > to ensure th
Hi all,
Task processes all its owned robust futex when it is exiting,
to ensure the futexes can be taken by other tasks.
Though this can not work good in sometimes.
Think about this scene：
1. A robust mutex is shared for two processes, each process has
multi threads to lock the mutex.
2. One
Darren Hart wrote on 2013/05/16 09:30:31:
>
> pgoff_t is an unsigned long, and page_to_pfn() returns an unsigned long.
> Since compound_idx can be assigned from page_to_pfn() and it is added
> with index in the return value, unsigned long seems like a better choice
> to me. Is there a specific
Mel Gorman wrote on 2013/05/15 22:20:35:
> Re: [PATCH] futex: bugfix for futex-key conflict when futex use hugepage
>
> On Wed, May 15, 2013 at 09:57:03PM +0800, Zhang Yi wrote:
> > The futex-keys of processes share futex determined by page-offset,
> > mapping-host, and mapping-index of the us
Mel Gorman wrote on 2013/05/07 23:20:07:
>
> Re: [PATCH] futex: bugfix for futex-key conflict when futex use hugepage
>
> On Tue, May 07, 2013 at 08:23:48PM +0800, Zhang Yi wrote:
> > diff -uprN linux3.9-orig/kernel/futex.c linux3.9/kernel/futex.c
> > --- linux3.9-orig/kernel/futex.c 2013-04-
Darren Hart wrote on 2013/04/18 22:54:30:
>
> "or it will exit later" I don't follow you there, it sounds like
> you are saying if we try to wake the exiting process, that process will
> be delayed and take longer to exit I don't think that is what you
> meant. Can you elaborate please?
Darren Hart wrote on 2013/04/19 10:45:00:
> >
> > BTW, have you seen the testcase in my other mail? It seems to be
> > rejected by LKML.
> >
>
> I did not receive it, did you also CC me?
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Technical Lead - Linux Ker
Darren Hart wrote on 2013/04/18 22:34:29:
> On 04/18/2013 01:05 AM, zhang.y...@zte.com.cn wrote:
> >
> > I have run futextest/performance/futex_wait for testing,
> > 5 times before make it long:
> > futex_wait: Measure FUTEX_WAIT operations per second
> > Arguments: iterations=1000
Darren Hart wrote on 2013/04/17 23:51:36:
> On 04/17/2013 08:26 AM, Dave Hansen wrote:
> > On 04/17/2013 07:18 AM, Darren Hart wrote:
> This also needs a comment in futex.h describing the usage of the
> offset field in union futex_key as well as above get_futex_key
> describing the
Darren Hart wrote on 2013/04/17 01:05:28:
>
> Performance isn't an issue here as this is an error path. The question
> is if the
> changed behavior will constitute a problem for existing applications.
Rather
> than a serialized cascading wake, we have them all wake at once. If an
> application
Darren Hart wrote on 2013/04/17 01:57:10:
> Again, a functional testcase in futextest would be a good idea. This
> helps validate the patch and also can be used to identify regressions in
> the future.
I will post the testcase code later.
>
> What is the max value of comp_idx? Are we at risk o
Dave Hansen wrote on 2013/04/17 02:37:40:
> Instead of bothering to store the index, why not just calculate it,
like:
>
> On 04/15/2013 08:37 PM, zhang.y...@zte.com.cn wrote:
> > +static inline int get_page_compound_index(struct page *page)
> > +{
> > + if (PageHead(page))
> > +
Hello,
The futex-keys of processes share futex determined by page-offset,
mapping-host, and
mapping-index of the user space address.
User appications using hugepage for futex may lead to futex-key conflict.
Assume there
are two or more futexes in diffrent normal pages of the hugepage, and eac
From: Zhang Yi
Hello,
The function handle_futex_death just wakes one thread, which may be not
enough when the owner process is dead. Think about this scene：
1. A robust futex is shared for two processes, each process has multi
threads try to get the lock.
2. One of the threads gets the lock,
20 matches
Mail list logo
