From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
anton@samba.org, Arnd Bergmann <arnd@arndb.de>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Travis <travis@sgi.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PULL] cpumask: finally make them variable size w/ CPUMASK_OFFSTACK.
Date: Mon, 14 May 2012 21:38:02 -0400 [thread overview]
Message-ID: <4FB1B37A.5050501@gmail.com> (raw)
In-Reply-To: <87zk9btqmu.fsf@rustcorp.com.au>
>> This code still slow than original. when calling reclaim path, new allocation is almost always
>> fail. then, your code almost always invoke all cpu batch invalidation. i.e. many ipi.
>
> I don't know this code. Does that happen often?Do we really need to
> optimize the out-of-memory path?
we don't need optimize out-of-memory path. but it's not out-of-memory path. our reclaim code
has two steps 1) purge small file cache (try_to_free_pages) 2) get new page (get_page_from_freelist).
but if you have smp box, it's racy. To success 1) doesn't guarantee to success 2). then, drain_all_pages()
is called frequently than you expected.
> But I should have used on_each_cpu_cond() helper which does this for us
> (except it falls back to individial IPIs) which would make this code
> neater.
Ah, yes. that definitely makes sense.
>>>> 2) When CONFIG_CPUMASK_OFFSTACK=n and NR_CPUS is relatively large, cpumask on stack may
>>>> cause stack overflow. because of, alloc_pages() can be called from
>>>> very deep call stack.
>>>
>>> You can't have large NR_CPUS without CONFIG_CPUMASK_OFFSTACK=y,
>>> otherwise you'll get many other stack overflows, too.
>>
>> Original code put cpumask bss instead stack then. :-)
>
> Yes, and this is what it looks like if we convert it directly, but I
> still don't want to encourage people to do this :(
>
> Cheers,
> Rusty.
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1179,7 +1179,7 @@ void drain_all_pages(void)
> * Allocate in the BSS so we wont require allocation in
> * direct reclaim path for CONFIG_CPUMASK_OFFSTACK=y
> */
> - static cpumask_t cpus_with_pcps;
> + static DECLARE_BITMAP(cpus_with_pcps, NR_CPUS);
>
> /*
> * We don't care about racing with CPU hotplug event
> @@ -1197,11 +1197,12 @@ void drain_all_pages(void)
> }
> }
> if (has_pcps)
> - cpumask_set_cpu(cpu,&cpus_with_pcps);
> + cpumask_set_cpu(cpu, to_cpumask(cpus_with_pcps));
> else
> - cpumask_clear_cpu(cpu,&cpus_with_pcps);
> + cpumask_clear_cpu(cpu, to_cpumask(cpus_with_pcps));
> }
> - on_each_cpu_mask(&cpus_with_pcps, drain_local_pages, NULL, 1);
> + on_each_cpu_mask(to_cpumask(cpus_with_pcps),
> + drain_local_pages, NULL, 1);
> }
Looks good to me. thanks.
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
prev parent reply other threads:[~2012-05-15 1:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 6:10 [PULL] cpumask: finally make them variable size w/ CPUMASK_OFFSTACK Rusty Russell
2012-05-09 8:44 ` Ingo Molnar
2012-05-10 0:29 ` Rusty Russell
2012-05-10 7:42 ` Ingo Molnar
2012-05-14 3:22 ` Rusty Russell
2012-05-10 1:32 ` KOSAKI Motohiro
2012-05-10 2:16 ` Rusty Russell
2012-05-10 2:43 ` KOSAKI Motohiro
2012-05-10 4:54 ` Rusty Russell
2012-05-10 6:42 ` KOSAKI Motohiro
2012-05-14 2:58 ` Rusty Russell
2012-05-15 1:38 ` KOSAKI Motohiro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB1B37A.5050501@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=anton@samba.org \
--cc=arnd@arndb.de \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=travis@sgi.com \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.