1. 26 11月, 2015 1 次提交
  2. 05 6月, 2015 3 次提交
  3. 28 5月, 2015 1 次提交
    • L
      kernel/params: constify struct kernel_param_ops uses · 9c27847d
      Luis R. Rodriguez 提交于
      Most code already uses consts for the struct kernel_param_ops,
      sweep the kernel for the last offending stragglers. Other than
      include/linux/moduleparam.h and kernel/params.c all other changes
      were generated with the following Coccinelle SmPL patch. Merge
      conflicts between trees can be handled with Coccinelle.
      
      In the future git could get Coccinelle merge support to deal with
      patch --> fail --> grammar --> Coccinelle --> new patch conflicts
      automatically for us on patches where the grammar is available and
      the patch is of high confidence. Consider this a feature request.
      
      Test compiled on x86_64 against:
      
      	* allnoconfig
      	* allmodconfig
      	* allyesconfig
      
      @ const_found @
      identifier ops;
      @@
      
      const struct kernel_param_ops ops = {
      };
      
      @ const_not_found depends on !const_found @
      identifier ops;
      @@
      
      -struct kernel_param_ops ops = {
      +const struct kernel_param_ops ops = {
      };
      
      Generated-by: Coccinelle SmPL
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Junio C Hamano <gitster@pobox.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: cocci@systeme.lip6.fr
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      9c27847d
  4. 20 5月, 2015 1 次提交
  5. 09 8月, 2014 1 次提交
  6. 20 11月, 2013 1 次提交
  7. 06 8月, 2012 2 次提交
  8. 08 4月, 2012 1 次提交
    • T
      KVM: MMU: Improve iteration through sptes from rmap · 1e3f42f0
      Takuya Yoshikawa 提交于
      Iteration using rmap_next(), the actual body is pte_list_next(), is
      inefficient: every time we call it we start from checking whether rmap
      holds a single spte or points to a descriptor which links more sptes.
      
      In the case of shadow paging, this quadratic total iteration cost is a
      problem.  Even for two dimensional paging, with EPT/NPT on, in which we
      almost always have a single mapping, the extra checks at the end of the
      iteration should be eliminated.
      
      This patch fixes this by introducing rmap_iterator which keeps the
      iteration context for the next search.  Furthermore the implementation
      of rmap_next() is splitted into two functions, rmap_get_first() and
      rmap_get_next(), to avoid repeatedly checking whether the rmap being
      iterated on has only one spte.
      
      Although there seemed to be only a slight change for EPT/NPT, the actual
      improvement was significant: we observed that GET_DIRTY_LOG for 1GB
      dirty memory became 15% faster than before.  This is probably because
      the new code is easy to make branch predictions.
      
      Note: we just remove pte_list_next() because we can think of parent_ptes
      as a reverse mapping.
      Signed-off-by: NTakuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      1e3f42f0
  9. 05 3月, 2012 1 次提交
  10. 24 2月, 2012 1 次提交
    • I
      static keys: Introduce 'struct static_key', static_key_true()/false() and... · c5905afb
      Ingo Molnar 提交于
      static keys: Introduce 'struct static_key', static_key_true()/false() and static_key_slow_[inc|dec]()
      
      So here's a boot tested patch on top of Jason's series that does
      all the cleanups I talked about and turns jump labels into a
      more intuitive to use facility. It should also address the
      various misconceptions and confusions that surround jump labels.
      
      Typical usage scenarios:
      
              #include <linux/static_key.h>
      
              struct static_key key = STATIC_KEY_INIT_TRUE;
      
              if (static_key_false(&key))
                      do unlikely code
              else
                      do likely code
      
      Or:
      
              if (static_key_true(&key))
                      do likely code
              else
                      do unlikely code
      
      The static key is modified via:
      
              static_key_slow_inc(&key);
              ...
              static_key_slow_dec(&key);
      
      The 'slow' prefix makes it abundantly clear that this is an
      expensive operation.
      
      I've updated all in-kernel code to use this everywhere. Note
      that I (intentionally) have not pushed through the rename
      blindly through to the lowest levels: the actual jump-label
      patching arch facility should be named like that, so we want to
      decouple jump labels from the static-key facility a bit.
      
      On non-jump-label enabled architectures static keys default to
      likely()/unlikely() branches.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NJason Baron <jbaron@redhat.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: a.p.zijlstra@chello.nl
      Cc: mathieu.desnoyers@efficios.com
      Cc: davem@davemloft.net
      Cc: ddaney.cavm@gmail.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20120222085809.GA26397@elte.huSigned-off-by: NIngo Molnar <mingo@elte.hu>
      c5905afb
  11. 27 12月, 2011 2 次提交
  12. 26 9月, 2011 1 次提交
  13. 24 7月, 2011 1 次提交
  14. 12 1月, 2011 1 次提交
  15. 24 10月, 2010 8 次提交