All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH 3/4] module: use a structure to encapsulate layout.
Date: Tue, 10 Nov 2015 12:11:46 +1030	[thread overview]
Message-ID: <878u66k4v9.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20151109094150.GF17308@twins.programming.kicks-ass.net>

Peter Zijlstra <peterz@infradead.org> writes:
> On Mon, Nov 09, 2015 at 02:53:56PM +1030, Rusty Russell wrote:
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 14b224967e7b..a0a3d6d9d5e8 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -108,13 +108,6 @@ static LIST_HEAD(modules);
>>   * Use a latched RB-tree for __module_address(); this allows us to use
>>   * RCU-sched lookups of the address from any context.
>>   *
>> - * Because modules have two address ranges: init and core, we need two
>> - * latch_tree_nodes entries. Therefore we need the back-pointer from
>> - * mod_tree_node.
>
> We still have the back-pointers, so removing all of that seems a little
> excessive.

Well, I thought about filling the hole with a "am_init" flag, and
putting the layouts in a [2] array, but seemed too cutesy.

>> - *
>> - * Because init ranges are short lived we mark them unlikely and have placed
>> - * them outside the critical cacheline in struct module.
>
> This information also isn't preserved.

Ah yeah, Intel still use 64-byte cachelines.  Still, this comment covers
what we actually care about:

 +#ifdef CONFIG_MODULES_TREE_LOOKUP
 +/* Only touch one cacheline for common rbtree-for-core-layout case. */
 +#define __module_layout_align ____cacheline_aligned
 +#else
 +#define __module_layout_align
 +#endif

> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Thanks!
Rusty.

  reply	other threads:[~2015-11-10  1:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-09  4:23 [PATCH 0/4] module RO/NX cleanups Rusty Russell
2015-11-09  4:23 ` [PATCH 1/4] module: Use the same logic for setting and unsetting RO/NX Rusty Russell
2015-11-09  4:23 ` [PATCH 2/4] gcov: use within_module() helper Rusty Russell
2015-11-09  8:19   ` Peter Oberparleiter
2015-11-09  4:23 ` [PATCH 3/4] module: use a structure to encapsulate layout Rusty Russell
2015-11-09  9:41   ` Peter Zijlstra
2015-11-10  1:41     ` Rusty Russell [this message]
2015-11-09 16:54   ` Josh Poimboeuf
2015-11-09  4:23 ` [PATCH 4/4] module: clean up RO/NX handling Rusty Russell
2015-11-09 19:51   ` Josh Poimboeuf
2015-11-10  1:57     ` Rusty Russell
2015-11-10  4:27       ` Josh Poimboeuf
2015-11-12  1:28         ` Rusty Russell
2015-11-12  3:41           ` Josh Poimboeuf

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=878u66k4v9.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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.