1. 30 8月, 2015 4 次提交
  2. 29 8月, 2015 2 次提交
  3. 28 8月, 2015 9 次提交
  4. 21 8月, 2015 3 次提交
  5. 18 8月, 2015 1 次提交
  6. 11 8月, 2015 2 次提交
  7. 08 8月, 2015 2 次提交
  8. 04 8月, 2015 1 次提交
  9. 30 7月, 2015 1 次提交
  10. 27 7月, 2015 2 次提交
  11. 22 7月, 2015 7 次提交
  12. 04 6月, 2015 1 次提交
  13. 02 6月, 2015 1 次提交
    • N
      openvswitch: include datapath actions with sampled-packet upcall to userspace · ccea7445
      Neil McKee 提交于
      If new optional attribute OVS_USERSPACE_ATTR_ACTIONS is added to an
      OVS_ACTION_ATTR_USERSPACE action, then include the datapath actions
      in the upcall.
      
      This Directly associates the sampled packet with the path it takes
      through the virtual switch. Path information currently includes mangling,
      encapsulation and decapsulation actions for tunneling protocols GRE,
      VXLAN, Geneve, MPLS and QinQ, but this extension requires no further
      changes to accommodate datapath actions that may be added in the
      future.
      
      Adding path information enhances visibility into complex virtual
      networks.
      Signed-off-by: NNeil McKee <neil.mckee@inmon.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ccea7445
  14. 14 5月, 2015 2 次提交
  15. 06 5月, 2015 1 次提交
  16. 15 4月, 2015 1 次提交
    • D
      mm: remove GFP_THISNODE · 4167e9b2
      David Rientjes 提交于
      NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
      
      GFP_THISNODE is a secret combination of gfp bits that have different
      behavior than expected.  It is a combination of __GFP_THISNODE,
      __GFP_NORETRY, and __GFP_NOWARN and is special-cased in the page
      allocator slowpath to fail without trying reclaim even though it may be
      used in combination with __GFP_WAIT.
      
      An example of the problem this creates: commit e97ca8e5 ("mm: fix
      GFP_THISNODE callers and clarify") fixed up many users of GFP_THISNODE
      that really just wanted __GFP_THISNODE.  The problem doesn't end there,
      however, because even it was a no-op for alloc_misplaced_dst_page(),
      which also sets __GFP_NORETRY and __GFP_NOWARN, and
      migrate_misplaced_transhuge_page(), where __GFP_NORETRY and __GFP_NOWAIT
      is set in GFP_TRANSHUGE.  Converting GFP_THISNODE to __GFP_THISNODE is a
      no-op in these cases since the page allocator special-cases
      __GFP_THISNODE && __GFP_NORETRY && __GFP_NOWARN.
      
      It's time to just remove GFP_THISNODE entirely.  We leave __GFP_THISNODE
      to restrict an allocation to a local node, but remove GFP_THISNODE and
      its obscurity.  Instead, we require that a caller clear __GFP_WAIT if it
      wants to avoid reclaim.
      
      This allows the aforementioned functions to actually reclaim as they
      should.  It also enables any future callers that want to do
      __GFP_THISNODE but also __GFP_NORETRY && __GFP_NOWARN to reclaim.  The
      rule is simple: if you don't want to reclaim, then don't set __GFP_WAIT.
      
      Aside: ovs_flow_stats_update() really wants to avoid reclaim as well, so
      it is unchanged.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Christoph Lameter <cl@linux.com>
      Acked-by: NPekka Enberg <penberg@kernel.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Pravin Shelar <pshelar@nicira.com>
      Cc: Jarno Rajahalme <jrajahalme@nicira.com>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4167e9b2