1. 06 9月, 2012 1 次提交
  2. 06 6月, 2012 1 次提交
  3. 16 4月, 2012 1 次提交
  4. 13 4月, 2012 1 次提交
  5. 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
  6. 17 1月, 2012 1 次提交
  7. 13 1月, 2012 1 次提交
  8. 25 12月, 2011 1 次提交
  9. 23 12月, 2011 1 次提交
  10. 06 12月, 2011 1 次提交
  11. 30 11月, 2011 2 次提交
  12. 18 11月, 2011 1 次提交
    • E
      net: use jump_label to shortcut RPS if not setup · adc9300e
      Eric Dumazet 提交于
      Most machines dont use RPS/RFS, and pay a fair amount of instructions in
      netif_receive_skb() / netif_rx() / get_rps_cpu() just to discover
      RPS/RFS is not setup.
      
      Add a jump_label named rps_needed.
      
      If no device rps_map or global rps_sock_flow_table is setup,
      netif_receive_skb() / netif_rx() do a single instruction instead of many
      ones, including conditional jumps.
      
      jmp +0    (if CONFIG_JUMP_LABEL=y)
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Tom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      adc9300e
  13. 17 11月, 2011 2 次提交
  14. 01 11月, 2011 1 次提交
  15. 16 9月, 2011 1 次提交
    • J
      net: consolidate and fix ethtool_ops->get_settings calling · 4bc71cb9
      Jiri Pirko 提交于
      This patch does several things:
      - introduces __ethtool_get_settings which is called from ethtool code and
        from drivers as well. Put ASSERT_RTNL there.
      - dev_ethtool_get_settings() is replaced by __ethtool_get_settings()
      - changes calling in drivers so rtnl locking is respected. In
        iboe_get_rate was previously ->get_settings() called unlocked. This
        fixes it. Also prb_calc_retire_blk_tmo() in af_packet.c had the same
        problem. Also fixed by calling __dev_get_by_index() instead of
        dev_get_by_index() and holding rtnl_lock for both calls.
      - introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
        so bnx2fc_if_create() and fcoe_if_create() are called locked as they
        are from other places.
      - use __ethtool_get_settings() in bonding code
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      
      v2->v3:
      	-removed dev_ethtool_get_settings()
      	-added ASSERT_RTNL into __ethtool_get_settings()
      	-prb_calc_retire_blk_tmo - use __dev_get_by_index() and lock
      	 around it and __ethtool_get_settings() call
      v1->v2:
              add missing export_symbol
      Reviewed-by: Ben Hutchings <bhutchings@solarflare.com> [except FCoE bits]
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bc71cb9
  16. 12 8月, 2011 1 次提交
  17. 02 8月, 2011 1 次提交
  18. 15 7月, 2011 1 次提交
  19. 13 6月, 2011 1 次提交
    • A
      Delay struct net freeing while there's a sysfs instance refering to it · a685e089
      Al Viro 提交于
      	* new refcount in struct net, controlling actual freeing of the memory
      	* new method in kobj_ns_type_operations (->drop_ns())
      	* ->current_ns() semantics change - it's supposed to be followed by
      corresponding ->drop_ns().  For struct net in case of CONFIG_NET_NS it bumps
      the new refcount; net_drop_ns() decrements it and calls net_free() if the
      last reference has been dropped.  Method renamed to ->grab_current_ns().
      	* old net_free() callers call net_drop_ns() instead.
      	* sysfs_exit_ns() is gone, along with a large part of callchain
      leading to it; now that the references stored in ->ns[...] stay valid we
      do not need to hunt them down and replace them with NULL.  That fixes
      problems in sysfs_lookup() and sysfs_readdir(), along with getting rid
      of sb->s_instances abuse.
      
      	Note that struct net *shutdown* logics has not changed - net_cleanup()
      is called exactly when it used to be called.  The only thing postponed by
      having a sysfs instance refering to that struct net is actual freeing of
      memory occupied by struct net.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      a685e089
  20. 17 5月, 2011 1 次提交
  21. 08 5月, 2011 3 次提交
  22. 30 4月, 2011 1 次提交
    • D
      ethtool: Call ethtool's get/set_settings callbacks with cleaned data · 8ae6daca
      David Decotigny 提交于
      This makes sure that when a driver calls the ethtool's
      get/set_settings() callback of another driver, the data passed to it
      is clean. This guarantees that speed_hi will be zeroed correctly if
      the called callback doesn't explicitely set it: we are sure we don't
      get a corrupted speed from the underlying driver. We also take care of
      setting the cmd field appropriately (ETHTOOL_GSET/SSET).
      
      This applies to dev_ethtool_get_settings(), which now makes sure it
      sets up that ethtool command parameter correctly before passing it to
      drivers. This also means that whoever calls dev_ethtool_get_settings()
      does not have to clean the ethtool command parameter. This function
      also becomes an exported symbol instead of an inline.
      
      All drivers visible to make allyesconfig under x86_64 have been
      updated.
      Signed-off-by: NDavid Decotigny <decot@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ae6daca
  23. 10 2月, 2011 1 次提交
  24. 25 1月, 2011 2 次提交
  25. 17 12月, 2010 1 次提交
  26. 02 12月, 2010 1 次提交
  27. 30 11月, 2010 2 次提交
  28. 29 11月, 2010 1 次提交
  29. 25 11月, 2010 1 次提交
    • T
      xps: Transmit Packet Steering · 1d24eb48
      Tom Herbert 提交于
      This patch implements transmit packet steering (XPS) for multiqueue
      devices.  XPS selects a transmit queue during packet transmission based
      on configuration.  This is done by mapping the CPU transmitting the
      packet to a queue.  This is the transmit side analogue to RPS-- where
      RPS is selecting a CPU based on receive queue, XPS selects a queue
      based on the CPU (previously there was an XPS patch from Eric
      Dumazet, but that might more appropriately be called transmit completion
      steering).
      
      Each transmit queue can be associated with a number of CPUs which will
      use the queue to send packets.  This is configured as a CPU mask on a
      per queue basis in:
      
      /sys/class/net/eth<n>/queues/tx-<n>/xps_cpus
      
      The mappings are stored per device in an inverted data structure that
      maps CPUs to queues.  In the netdevice structure this is an array of
      num_possible_cpu structures where each structure holds and array of
      queue_indexes for queues which that CPU can use.
      
      The benefits of XPS are improved locality in the per queue data
      structures.  Also, transmit completions are more likely to be done
      nearer to the sending thread, so this should promote locality back
      to the socket on free (e.g. UDP).  The benefits of XPS are dependent on
      cache hierarchy, application load, and other factors.  XPS would
      nominally be configured so that a queue would only be shared by CPUs
      which are sharing a cache, the degenerative configuration woud be that
      each CPU has it's own queue.
      
      Below are some benchmark results which show the potential benfit of
      this patch.  The netperf test has 500 instances of netperf TCP_RR test
      with 1 byte req. and resp.
      
      bnx2x on 16 core AMD
         XPS (16 queues, 1 TX queue per CPU)  1234K at 100% CPU
         No XPS (16 queues)                   996K at 100% CPU
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d24eb48
  30. 19 11月, 2010 1 次提交
    • J
      net: zero kobject in rx_queue_release · 7d8e76bf
      John Fastabend 提交于
      netif_set_real_num_rx_queues() can decrement and increment
      the number of rx queues. For example ixgbe does this as
      features and offloads are toggled. Presumably this could
      also happen across down/up on most devices if the available
      resources changed (cpu offlined).
      
      The kobject needs to be zero'd in this case so that the
      state is not preserved across kobject_put()/kobject_init_and_add().
      
      This resolves the following error report.
      
      ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX
      kobject (ffff880324b83210): tried to init an initialized object, something is seriously wrong.
      Pid: 1972, comm: lldpad Not tainted 2.6.37-rc18021qaz+ #169
      Call Trace:
       [<ffffffff8121c940>] kobject_init+0x3a/0x83
       [<ffffffff8121cf77>] kobject_init_and_add+0x23/0x57
       [<ffffffff8107b800>] ? mark_lock+0x21/0x267
       [<ffffffff813c6d11>] net_rx_queue_update_kobjects+0x63/0xc6
       [<ffffffff813b5e0e>] netif_set_real_num_rx_queues+0x5f/0x78
       [<ffffffffa0261d49>] ixgbe_set_num_queues+0x1c6/0x1ca [ixgbe]
       [<ffffffffa0262509>] ixgbe_init_interrupt_scheme+0x1e/0x79c [ixgbe]
       [<ffffffffa0274596>] ixgbe_dcbnl_set_state+0x167/0x189 [ixgbe]
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d8e76bf
  31. 18 11月, 2010 1 次提交
    • J
      net: zero kobject in rx_queue_release · 9ea19481
      John Fastabend 提交于
      netif_set_real_num_rx_queues() can decrement and increment
      the number of rx queues. For example ixgbe does this as
      features and offloads are toggled. Presumably this could
      also happen across down/up on most devices if the available
      resources changed (cpu offlined).
      
      The kobject needs to be zero'd in this case so that the
      state is not preserved across kobject_put()/kobject_init_and_add().
      
      This resolves the following error report.
      
      ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX
      kobject (ffff880324b83210): tried to init an initialized object, something is seriously wrong.
      Pid: 1972, comm: lldpad Not tainted 2.6.37-rc18021qaz+ #169
      Call Trace:
       [<ffffffff8121c940>] kobject_init+0x3a/0x83
       [<ffffffff8121cf77>] kobject_init_and_add+0x23/0x57
       [<ffffffff8107b800>] ? mark_lock+0x21/0x267
       [<ffffffff813c6d11>] net_rx_queue_update_kobjects+0x63/0xc6
       [<ffffffff813b5e0e>] netif_set_real_num_rx_queues+0x5f/0x78
       [<ffffffffa0261d49>] ixgbe_set_num_queues+0x1c6/0x1ca [ixgbe]
       [<ffffffffa0262509>] ixgbe_init_interrupt_scheme+0x1e/0x79c [ixgbe]
       [<ffffffffa0274596>] ixgbe_dcbnl_set_state+0x167/0x189 [ixgbe]
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ea19481
  32. 16 11月, 2010 1 次提交
  33. 26 10月, 2010 1 次提交
  34. 09 10月, 2010 1 次提交