[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49C250DB.3050707@cosmosbay.com>
Date: Thu, 19 Mar 2009 15:04:11 +0100
From: Eric Dumazet <dada1@...mosbay.com>
To: David Miller <davem@...emloft.net>
CC: sven@...bigcorporation.com, ghaskins@...ell.com, vernux@...ibm.com,
andi@...stfloor.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
pmullaney@...ell.com
Subject: [PATCH] net: reorder struct Qdisc for better SMP performance
David Miller a écrit :
> From: Eric Dumazet <dada1@...mosbay.com>
> Date: Thu, 19 Mar 2009 06:49:19 +0100
>
>> Still, there is room for improvements, since :
>>
>> 1) default qdisc is pfifo_fast. This beast uses three sk_buff_head (96 bytes)
>> where it could use 3 smaller list_head (3 * 16 = 48 bytes on x86_64)
>>
>> (assuming sizeof(spinlock_t) is only 4 bytes, but it's more than that
>> on various situations (LOCKDEP, ...)
>
> I already plan on doing this, skb->{next,prev} will be replaced with a
> list_head and nearly all of the sk_buff_head usage will simply
> disappear. It's a lot of work because every piece of SKB queue
> handling code has to be sanitized to only use the interfaces in
> linux/skbuff.h and lots of extremely ugly code like the PPP
> defragmenter make many non-trivial direct skb->{next,prev}
> manipulations.
>
>> 2) struct Qdisc layout could be better, letting read mostly fields
>> at beginning of structure. (ie move 'dev_queue', 'next_sched', reshape_fail,
>> u32_node, __parent, ...)
>
> I have no problem with your struct layout changes, submit it formally.
OK here is the layout change then ;)
Thank you
[PATCH] net: reorder struct Qdisc for better SMP performance
dev_queue_xmit() needs to dirty fields "state", "q", "bstats" and "qstats"
On x86_64 arch, they currently span three cache lines, involving more
cache line ping pongs than necessary, making longer holding of queue spinlock.
We can reduce this to one cache line, by grouping all read-mostly fields
at the beginning of structure. (Or should I say, all highly modified fields
at the end :) )
Before patch :
offsetof(struct Qdisc, state)=0x38
offsetof(struct Qdisc, q)=0x48
offsetof(struct Qdisc, bstats)=0x80
offsetof(struct Qdisc, qstats)=0x90
sizeof(struct Qdisc)=0xc8
After patch :
offsetof(struct Qdisc, state)=0x80
offsetof(struct Qdisc, q)=0x88
offsetof(struct Qdisc, bstats)=0xa0
offsetof(struct Qdisc, qstats)=0xac
sizeof(struct Qdisc)=0xc0
Signed-off-by: Eric Dumazet <dada1@...mosbay.com>
---
include/linux/gen_stats.h | 2 +-
include/net/sch_generic.h | 21 ++++++++++++---------
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/include/linux/gen_stats.h b/include/linux/gen_stats.h
index 13f4e74..0ffa41d 100644
--- a/include/linux/gen_stats.h
+++ b/include/linux/gen_stats.h
@@ -22,7 +22,7 @@ struct gnet_stats_basic
{
__u64 bytes;
__u32 packets;
-};
+} __attribute__ ((packed));
/**
* struct gnet_stats_rate_est - rate estimator
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index f8c4742..b0ae100 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -48,18 +48,10 @@ struct Qdisc
int padded;
struct Qdisc_ops *ops;
struct qdisc_size_table *stab;
+ struct list_head list;
u32 handle;
u32 parent;
atomic_t refcnt;
- unsigned long state;
- struct sk_buff *gso_skb;
- struct sk_buff_head q;
- struct netdev_queue *dev_queue;
- struct Qdisc *next_sched;
- struct list_head list;
-
- struct gnet_stats_basic bstats;
- struct gnet_stats_queue qstats;
struct gnet_stats_rate_est rate_est;
int (*reshape_fail)(struct sk_buff *skb,
struct Qdisc *q);
@@ -70,6 +62,17 @@ struct Qdisc
* and it will live until better solution will be invented.
*/
struct Qdisc *__parent;
+ struct netdev_queue *dev_queue;
+ struct Qdisc *next_sched;
+
+ struct sk_buff *gso_skb;
+ /*
+ * For performance sake on SMP, we put highly modified fields at the end
+ */
+ unsigned long state;
+ struct sk_buff_head q;
+ struct gnet_stats_basic bstats;
+ struct gnet_stats_queue qstats;
};
struct Qdisc_class_ops
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists