linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: jbaron@redhat.com, rostedt@goodmis.org, mingo@elte.hu
Cc: linux-kernel@vger.kernel.org
Subject: [PATCHv2 0/2] jump_label,x86: make batch update of jump_label entries
Date: Wed,  4 May 2011 11:41:41 +0200	[thread overview]
Message-ID: <1304502103-3228-1-git-send-email-jolsa@redhat.com> (raw)
In-Reply-To: <1304023961-12741-1-git-send-email-jolsa@redhat.com>

hi,

I'm changing the jump label update code to use batch processing
for x86 architectures. 

Currently each jump label update calls text_poke_smp for each
jump label key entry. Thus one key update ends up calling stop
machine multiple times.

This patch is using text_poke_smp_batch, which is called for
all the key's entries. Thus ensuring the stop machine is called
only once per jump_label key.

attached patches:
1/2 - jump_label,x86: use text_poke_smp_batch for entries update
	- added jump_label_update_end function which is paired with
	the key's entries update
	- jump_label_update_end calls arch_jump_label_update_end which
	is overloaded by x86 arch and makes the batch update of all the
	entries queued by arch_jump_label_transform function.

2/2 - jump_label,x86: using static arrays before dynamic allocation is needed
	- in the first patch, the queue array, which stores jump_label
	entries is allocated/resized dynamically.
	- due to the fact that many jump_label entries have low number
	of callers, it seems appropriate to use static sized array
	when the update starts and if needed (in case of high number
	of jump_label entries) allocate/use the dynamic array


Patch 2/2 and could be ommited if the benefit/complexity ratio
would seem too low.. ;)

I tested this on x86 and s390 archs.

v2 changes:
 - queueing all entries for single key and process them
   all at one time

wrb,
jirka
---
 arch/x86/kernel/jump_label.c |  177 +++++++++++++++++++++++++++++++++++++++--
 include/linux/jump_label.h   |    1 +
 kernel/jump_label.c          |   16 ++++-
 3 files changed, 183 insertions(+), 11 deletions(-)

  parent reply	other threads:[~2011-05-04  9:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28 20:52 [PATCH] jump_label,x86: use text_poke_smp_batch for entries update Jiri Olsa
2011-04-29 15:15 ` Jason Baron
2011-04-29 15:37   ` Jiri Olsa
2011-05-04  9:41 ` Jiri Olsa [this message]
2011-05-04  9:41   ` [PATCHv2 1/2] " Jiri Olsa
2011-05-04  9:41   ` [PATCHv2 2/2] jump_label,x86: using static arrays before dynamic allocation is needed Jiri Olsa
2011-05-09 18:38   ` [PATCHv3] jump_label,x86: make batch update of jump_label entries Jiri Olsa
2011-05-09 19:27     ` Jason Baron
2011-05-23 16:45       ` Jiri Olsa
2011-05-23 20:53         ` Steven Rostedt

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=1304502103-3228-1-git-send-email-jolsa@redhat.com \
    --to=jolsa@redhat.com \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).