From: raz ben yehuda <raziebe@gmail.com>
To: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Chris Friesen <cfriesen@nortel.com>,
Andrew Morton <akpm@linux-foundation.org>,
mingo@elte.hu, peterz@infradead.org, maximlevitsky@gmail.com,
efault@gmx.de, wiseman@macs.biu.ac.il,
linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org
Subject: Re: RFC: THE OFFLINE SCHEDULER
Date: Fri, 28 Aug 2009 18:22:43 +0300 [thread overview]
Message-ID: <1251472963.3705.26.camel@raz> (raw)
In-Reply-To: <4A97DAE7.40603@redhat.com>
On Fri, 2009-08-28 at 09:25 -0400, Rik van Riel wrote:
> raz ben yehuda wrote:
>
> > yes. latency is a crucial property.
>
> In the case of network packets, wouldn't you get a lower
> latency by transmitting the packet from the CPU that
> knows the packet should be transmitted, instead of sending
> an IPI to another CPU and waiting for that CPU to do the
> work?
Hello Rik
If I understand what you are saying, you say that I pass 1.5K packets to
a offline CPU ?
If so, then this is not what I do, because you are very right, it does
not make any sense.
I do not pass packets to an offline cpu , i pass assignments. an
assignment is a buffer with some context of what do with it (like aio)
and a buffer is of ~1MB. Also, the offline processor holds the network
interface as it own interface. No two offline processors transmit over a
single interface.( I modified the bonding driver to work with offline
processor for that ). I am aware of network queue per processors, but
benchmarks proved this was better.( I do not have these benchmarks
now).
Also these engines do not release any sk_buffs to the operating system,
these packets are being reused over and over to reduce latency of
allocating memory and cache misses.
Also, in some cases I disabled the transmit interrupts and I released
packets ( --skb->users was still greater than 0, not really release ) in
an offline context.I learned it from the chelsio driver. This way, I
reduced more load from the operating system. It proved to be better in
large 1Gbps arrays and was able to remove atomic_inc atomic_dec in some
variants of the code, atomic operations cost a lot.
in MSI cards I did not find it useful.in the example i showed, i use MSI
and system is almost idle.
Also, as I recall , IPI will not pass to an offladed processor. offsced
it runs NMI.
Also, I would to express my apologies if any of this correspondence
seems to be as I am trying to PR offsched. I am not.
> Inter-CPU communication has always been the bottleneck
> when it comes to SMP performance. Why does adding more
> inter-CPU communication make your system faster, instead
> of slower like one would expect?
>
next prev parent reply other threads:[~2009-08-28 15:22 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-22 23:27 RFC: THE OFFLINE SCHEDULER raz ben yehuda
2009-08-23 5:21 ` Mike Galbraith
2009-08-23 9:09 ` raz ben yehuda
2009-08-23 7:30 ` Mike Galbraith
2009-08-23 11:05 ` raz ben yehuda
2009-08-23 9:52 ` Mike Galbraith
2009-08-25 15:23 ` Christoph Lameter
2009-08-25 17:56 ` Mike Galbraith
2009-08-25 18:03 ` Christoph Lameter
2009-08-25 18:12 ` Mike Galbraith
[not found] ` <5d96567b0908251522m3fd4ab98n76a52a34a11e874c@mail.gmail.com>
2009-08-25 22:32 ` Fwd: " Raz
2009-08-25 19:08 ` Peter Zijlstra
2009-08-25 19:18 ` Christoph Lameter
2009-08-25 19:22 ` Chris Friesen
2009-08-25 20:35 ` Sven-Thorsten Dietrich
2009-08-26 5:31 ` Peter Zijlstra
2009-08-26 10:29 ` raz ben yehuda
2009-08-26 8:02 ` Mike Galbraith
2009-08-26 8:16 ` Raz
2009-08-26 8:16 ` Raz
2009-08-26 13:47 ` Christoph Lameter
2009-08-26 14:45 ` Maxim Levitsky
2009-08-26 14:54 ` raz ben yehuda
2009-08-26 15:06 ` Pekka Enberg
2009-08-26 15:11 ` raz ben yehuda
2009-08-26 15:30 ` Peter Zijlstra
2009-08-26 15:41 ` Christoph Lameter
2009-08-26 16:03 ` Peter Zijlstra
2009-08-26 16:16 ` Pekka Enberg
2009-08-26 16:20 ` Christoph Lameter
2009-08-26 18:04 ` Ingo Molnar
2009-08-26 19:15 ` Christoph Lameter
2009-08-26 19:32 ` Ingo Molnar
2009-08-26 20:40 ` Christoph Lameter
2009-08-26 20:50 ` Andrew Morton
2009-08-26 21:09 ` Christoph Lameter
2009-08-26 21:15 ` Chris Friesen
2009-08-26 21:37 ` raz ben yehuda
2009-08-27 16:51 ` Chris Friesen
2009-08-27 17:04 ` Christoph Lameter
2009-08-27 21:09 ` Thomas Gleixner
2009-08-27 22:22 ` Gregory Haskins
2009-08-28 2:15 ` Rik van Riel
2009-08-28 3:33 ` Gregory Haskins
2009-08-28 3:33 ` Gregory Haskins
2009-08-28 4:27 ` Gregory Haskins
2009-08-28 4:27 ` Gregory Haskins
2009-08-28 10:26 ` Thomas Gleixner
2009-08-28 18:57 ` Christoph Lameter
2009-08-28 19:23 ` Thomas Gleixner
2009-08-28 19:52 ` Christoph Lameter
2009-08-28 20:00 ` Thomas Gleixner
2009-08-28 20:21 ` Christoph Lameter
2009-08-28 20:34 ` Thomas Gleixner
2009-08-31 19:19 ` Christoph Lameter
2009-08-31 17:44 ` Roland Dreier
2009-09-01 18:42 ` Christoph Lameter
2009-09-01 16:15 ` Roland Dreier
2009-08-29 17:03 ` jim owens
2009-08-31 19:22 ` Christoph Lameter
2009-08-31 15:33 ` Peter Zijlstra
2009-09-01 18:46 ` Christoph Lameter
2009-08-28 6:14 ` Peter Zijlstra
2009-08-27 23:51 ` Chris Friesen
2009-08-28 0:44 ` Thomas Gleixner
2009-08-28 21:20 ` Chris Friesen
2009-08-28 21:20 ` Chris Friesen
2009-08-28 18:43 ` Christoph Lameter
2009-08-27 21:33 ` raz ben yehuda
2009-08-27 22:05 ` Thomas Gleixner
2009-08-28 8:38 ` raz ben yehuda
2009-08-28 10:05 ` Thomas Gleixner
2009-08-28 13:25 ` Rik van Riel
2009-08-28 13:37 ` jim owens
2009-08-28 15:22 ` raz ben yehuda [this message]
2009-08-26 21:34 ` Ingo Molnar
2009-08-27 2:55 ` Frank Ch. Eigler
2009-08-26 21:34 ` raz ben yehuda
2009-08-26 21:08 ` Ingo Molnar
2009-08-26 21:26 ` Christoph Lameter
2009-08-26 21:32 ` raz ben yehuda
2009-08-27 7:15 ` Mike Galbraith
2009-08-26 15:37 ` Chetan.Loke
2009-08-26 15:21 ` Pekka Enberg
2009-08-25 21:09 ` Éric Piel
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=1251472963.3705.26.camel@raz \
--to=raziebe@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=wiseman@macs.biu.ac.il \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.