* Re: Flow Control and Port Mirroring Revisited
From: Michael S. Tsirkin @ 2011-01-24 19:42 UTC (permalink / raw)
To: Rick Jones
Cc: Simon Horman, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <4D3DCC99.5050101@hp.com>
On Mon, Jan 24, 2011 at 11:01:45AM -0800, Rick Jones wrote:
> Michael S. Tsirkin wrote:
> >On Mon, Jan 24, 2011 at 10:27:55AM -0800, Rick Jones wrote:
> >
> >>>Just to block netperf you can send it SIGSTOP :)
> >>>
> >>
> >>Clever :) One could I suppose achieve the same result by making the
> >>remote receive socket buffer size smaller than the UDP message size
> >>and then not worry about having to learn the netserver's PID to send
> >>it the SIGSTOP. I *think* the semantics will be substantially the
> >>same?
> >
> >
> >If you could set, it, yes. But at least linux ignores
> >any value substantially smaller than 1K, and then
> >multiplies that by 2:
> >
> > case SO_RCVBUF:
> > /* Don't error on this BSD doesn't and if you think
> > about it this is right. Otherwise apps have to
> > play 'guess the biggest size' games. RCVBUF/SNDBUF
> > are treated in BSD as hints */
> >
> > if (val > sysctl_rmem_max)
> > val = sysctl_rmem_max;
> >set_rcvbuf: sk->sk_userlocks |=
> >SOCK_RCVBUF_LOCK;
> >
> > /*
> > * We double it on the way in to account for
> > * "struct sk_buff" etc. overhead. Applications
> > * assume that the SO_RCVBUF setting they make will
> > * allow that much actual data to be received on that
> > * socket.
> > *
> > * Applications are unaware that "struct sk_buff" and
> > * other overheads allocate from the receive buffer
> > * during socket buffer allocation.
> >*
> > * And after considering the possible alternatives,
> > * returning the value we actually used in getsockopt
> > * is the most desirable behavior.
> > */ if ((val * 2) <
> >SOCK_MIN_RCVBUF)
> > sk->sk_rcvbuf = SOCK_MIN_RCVBUF;
> > else
> > sk->sk_rcvbuf = val * 2;
> >
> >and
> >
> >/* * Since sk_rmem_alloc sums skb->truesize,
> >even a small frame might need
> > * sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak
> > */ #define SOCK_MIN_RCVBUF (2048 + sizeof(struct
> >sk_buff))
>
> Pity - seems to work back on 2.6.26:
Hmm, that code is there at least as far back as 2.6.12.
> raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1 -m 1024
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> localhost (127.0.0.1) port 0 AF_INET : histogram
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 124928 1024 10.00 2882334 0 2361.17
> 256 10.00 0 0.00
>
> raj@tardy:~/netperf2_trunk$ uname -a
> Linux tardy 2.6.26-2-amd64 #1 SMP Sun Jun 20 20:16:30 UTC 2010 x86_64 GNU/Linux
>
> Still, even with that (or SIGSTOP) we don't really know where the
> packets were dropped right? There is no guarantee they weren't
> dropped before they got to the socket buffer
>
> happy benchmarking,
> rick jones
Right. Better send to a port with no socket listening there,
that would drop the packet at an early (if not at the earliest
possible) opportunity.
> PS - here is with a -S 1024 option:
>
> raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1024 -m 1024
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> localhost (127.0.0.1) port 0 AF_INET : histogram
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 124928 1024 10.00 1679269 0 1375.64
> 2048 10.00 1490662 1221.13
>
> showing that there is a decent chance that many of the frames were
> dropped at the socket buffer, but not all - I suppose I could/should
> be checking netstat stats... :)
>
> And just a little more, only because I was curious :)
>
> raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1M -m 257
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> localhost (127.0.0.1) port 0 AF_INET : histogram
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 124928 257 10.00 1869134 0 384.29
> 262142 10.00 1869134 384.29
>
> raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1 -m 257
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> localhost (127.0.0.1) port 0 AF_INET : histogram
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 124928 257 10.00 3076363 0 632.49
> 256 10.00 0 0.00
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Rick Jones @ 2011-01-24 19:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Simon Horman, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110124183626.GB29941@redhat.com>
Michael S. Tsirkin wrote:
> On Mon, Jan 24, 2011 at 10:27:55AM -0800, Rick Jones wrote:
>
>>>Just to block netperf you can send it SIGSTOP :)
>>>
>>
>>Clever :) One could I suppose achieve the same result by making the
>>remote receive socket buffer size smaller than the UDP message size
>>and then not worry about having to learn the netserver's PID to send
>>it the SIGSTOP. I *think* the semantics will be substantially the
>>same?
>
>
> If you could set, it, yes. But at least linux ignores
> any value substantially smaller than 1K, and then
> multiplies that by 2:
>
> case SO_RCVBUF:
> /* Don't error on this BSD doesn't and if you think
> about it this is right. Otherwise apps have to
> play 'guess the biggest size' games. RCVBUF/SNDBUF
> are treated in BSD as hints */
>
> if (val > sysctl_rmem_max)
> val = sysctl_rmem_max;
> set_rcvbuf:
> sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
>
> /*
> * We double it on the way in to account for
> * "struct sk_buff" etc. overhead. Applications
> * assume that the SO_RCVBUF setting they make will
> * allow that much actual data to be received on that
> * socket.
> *
> * Applications are unaware that "struct sk_buff" and
> * other overheads allocate from the receive buffer
> * during socket buffer allocation.
> *
> * And after considering the possible alternatives,
> * returning the value we actually used in getsockopt
> * is the most desirable behavior.
> */
> if ((val * 2) < SOCK_MIN_RCVBUF)
> sk->sk_rcvbuf = SOCK_MIN_RCVBUF;
> else
> sk->sk_rcvbuf = val * 2;
>
> and
>
> /*
> * Since sk_rmem_alloc sums skb->truesize, even a small frame might need
> * sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak
> */
> #define SOCK_MIN_RCVBUF (2048 + sizeof(struct sk_buff))
Pity - seems to work back on 2.6.26:
raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1 -m 1024
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost
(127.0.0.1) port 0 AF_INET : histogram
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
124928 1024 10.00 2882334 0 2361.17
256 10.00 0 0.00
raj@tardy:~/netperf2_trunk$ uname -a
Linux tardy 2.6.26-2-amd64 #1 SMP Sun Jun 20 20:16:30 UTC 2010 x86_64 GNU/Linux
Still, even with that (or SIGSTOP) we don't really know where the packets were
dropped right? There is no guarantee they weren't dropped before they got to
the socket buffer
happy benchmarking,
rick jones
PS - here is with a -S 1024 option:
raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1024 -m 1024
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost
(127.0.0.1) port 0 AF_INET : histogram
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
124928 1024 10.00 1679269 0 1375.64
2048 10.00 1490662 1221.13
showing that there is a decent chance that many of the frames were dropped at
the socket buffer, but not all - I suppose I could/should be checking netstat
stats... :)
And just a little more, only because I was curious :)
raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1M -m 257
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost
(127.0.0.1) port 0 AF_INET : histogram
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
124928 257 10.00 1869134 0 384.29
262142 10.00 1869134 384.29
raj@tardy:~/netperf2_trunk$ src/netperf -t UDP_STREAM -- -S 1 -m 257
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost
(127.0.0.1) port 0 AF_INET : histogram
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
124928 257 10.00 3076363 0 632.49
256 10.00 0 0.00
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Michael S. Tsirkin @ 2011-01-24 18:36 UTC (permalink / raw)
To: Rick Jones
Cc: Simon Horman, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <4D3DC4AB.1000207@hp.com>
On Mon, Jan 24, 2011 at 10:27:55AM -0800, Rick Jones wrote:
> >
> >Just to block netperf you can send it SIGSTOP :)
> >
>
> Clever :) One could I suppose achieve the same result by making the
> remote receive socket buffer size smaller than the UDP message size
> and then not worry about having to learn the netserver's PID to send
> it the SIGSTOP. I *think* the semantics will be substantially the
> same?
If you could set, it, yes. But at least linux ignores
any value substantially smaller than 1K, and then
multiplies that by 2:
case SO_RCVBUF:
/* Don't error on this BSD doesn't and if you think
about it this is right. Otherwise apps have to
play 'guess the biggest size' games. RCVBUF/SNDBUF
are treated in BSD as hints */
if (val > sysctl_rmem_max)
val = sysctl_rmem_max;
set_rcvbuf:
sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
/*
* We double it on the way in to account for
* "struct sk_buff" etc. overhead. Applications
* assume that the SO_RCVBUF setting they make will
* allow that much actual data to be received on that
* socket.
*
* Applications are unaware that "struct sk_buff" and
* other overheads allocate from the receive buffer
* during socket buffer allocation.
*
* And after considering the possible alternatives,
* returning the value we actually used in getsockopt
* is the most desirable behavior.
*/
if ((val * 2) < SOCK_MIN_RCVBUF)
sk->sk_rcvbuf = SOCK_MIN_RCVBUF;
else
sk->sk_rcvbuf = val * 2;
and
/*
* Since sk_rmem_alloc sums skb->truesize, even a small frame might need
* sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak
*/
#define SOCK_MIN_RCVBUF (2048 + sizeof(struct sk_buff))
> Both will be drops at the socket buffer, albeit for for
> different reasons. The "too small socket buffer" version though
> doesn't require one remember to "wake" the netserver in time to have
> it send results back to netperf without netperf tossing-up an error
> and not reporting any statistics.
>
> Also, netperf has a "no control connection" mode where you can, in
> effect cause it to send UDP datagrams out into the void - I put it
> there to allow folks to test against the likes of echo discard and
> chargen services but it may have a use here. Requires that one
> specify the destination IP and port for the "data connection"
> explicitly via the test-specific options. In that mode the only
> stats reported are those local to netperf rather than netserver.
Ah, sounds perfect.
> happy benchmarking,
>
> rick jones
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Rick Jones @ 2011-01-24 18:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Simon Horman, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110123103902.GA28585@redhat.com>
>
> Just to block netperf you can send it SIGSTOP :)
>
Clever :) One could I suppose achieve the same result by making the remote
receive socket buffer size smaller than the UDP message size and then not worry
about having to learn the netserver's PID to send it the SIGSTOP. I *think* the
semantics will be substantially the same? Both will be drops at the socket
buffer, albeit for for different reasons. The "too small socket buffer" version
though doesn't require one remember to "wake" the netserver in time to have it
send results back to netperf without netperf tossing-up an error and not
reporting any statistics.
Also, netperf has a "no control connection" mode where you can, in effect cause
it to send UDP datagrams out into the void - I put it there to allow folks to
test against the likes of echo discard and chargen services but it may have a
use here. Requires that one specify the destination IP and port for the "data
connection" explicitly via the test-specific options. In that mode the only
stats reported are those local to netperf rather than netserver.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH 2/3] kvm hypervisor : Add hypercalls to support pv-ticketlock
From: Jeremy Fitzhardinge @ 2011-01-24 17:49 UTC (permalink / raw)
To: Rik van Riel
Cc: Xen-devel, Mathieu Desnoyers, Nick Piggin, kvm, Peter Zijlstra,
vatsa, Jan Beulich, Linux Kernel Mailing List,
Jeremy Fitzhardinge, suzuki, Avi Kivity, H. Peter Anvin,
Américo Wang, Eric Dumazet, Linux Virtualization
In-Reply-To: <4D3AEF7A.1050709@redhat.com>
On 01/22/2011 06:53 AM, Rik van Riel wrote:
> The main question that remains is whether the PV ticketlocks are
> a large enough improvement to also merge those. I expect they
> will be, and we'll see so in the benchmark numbers.
The pathological worst-case of ticket locks in a virtual environment
isn't very hard to hit, so I expect they'll make a huge difference
there. On lightly loaded systems (little or no CPU overcommit) then
they should be close to a no-op.
J
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Simon Horman @ 2011-01-23 13:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rick Jones, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110123103902.GA28585@redhat.com>
On Sun, Jan 23, 2011 at 12:39:02PM +0200, Michael S. Tsirkin wrote:
> On Sun, Jan 23, 2011 at 05:38:49PM +1100, Simon Horman wrote:
> > On Sat, Jan 22, 2011 at 11:57:42PM +0200, Michael S. Tsirkin wrote:
> > > On Sat, Jan 22, 2011 at 10:11:52AM +1100, Simon Horman wrote:
> > > > On Fri, Jan 21, 2011 at 11:59:30AM +0200, Michael S. Tsirkin wrote:
[snip]
> > > > > Hmm, what is this supposed to measure? Basically each time you run an
> > > > > un-paced UDP_STREAM you get some random load on the network.
> > > > > You can't tell what it was exactly, only that it was between
> > > > > the send and receive throughput.
> > > >
> > > > Rick mentioned in another email that I messed up my test parameters a bit,
> > > > so I will re-run the tests, incorporating his suggestions.
> > > >
> > > > What I was attempting to measure was the effect of an unpaced UDP_STREAM
> > > > on the latency of more moderated traffic. Because I am interested in
> > > > what effect an abusive guest has on other guests and how that my be
> > > > mitigated.
> > > >
> > > > Could you suggest some tests that you feel are more appropriate?
> > >
> > > Yes. To refraze my concern in these terms, besides the malicious guest
> > > you have another software in host (netperf) that interferes with
> > > the traffic, and it cooperates with the malicious guest.
> > > Right?
> >
> > Yes, that is the scenario in this test.
>
> Yes but I think that you want to put some controlled load on host.
> Let's assume that we impove the speed somehow and now you can push more
> bytes per second without loss. Result might be a regression in your
> test because you let the guest push "as much as it can" and suddenly it
> can push more data through. OTOH with packet loss the load on host is
> anywhere in between send and receive throughput: there's no easy way to
> measure it from netperf: the earlier some buffers overrun, the earlier
> the packets get dropped and the less the load on host.
>
> This is why I say that to get a specific
> load on host you want to limit the sender
> to a specific BW and then either
> - make sure packet loss % is close to 0.
> - make sure packet loss % is close to 100%.
Thanks, and sorry for being a bit slow. I now see what you have
been getting at with regards to limiting the tests.
I will see about getting some numbers based on your suggestions.
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Michael S. Tsirkin @ 2011-01-23 10:39 UTC (permalink / raw)
To: Simon Horman
Cc: Rick Jones, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110123063849.GB2673@verge.net.au>
On Sun, Jan 23, 2011 at 05:38:49PM +1100, Simon Horman wrote:
> On Sat, Jan 22, 2011 at 11:57:42PM +0200, Michael S. Tsirkin wrote:
> > On Sat, Jan 22, 2011 at 10:11:52AM +1100, Simon Horman wrote:
> > > On Fri, Jan 21, 2011 at 11:59:30AM +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
> > > > > [ Trimmed Eric from CC list as vger was complaining that it is too long ]
> > > > >
> > > > > On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
> > > > > > >So it won't be all that simple to implement well, and before we try,
> > > > > > >I'd like to know whether there are applications that are helped
> > > > > > >by it. For example, we could try to measure latency at various
> > > > > > >pps and see whether the backpressure helps. netperf has -b, -w
> > > > > > >flags which might help these measurements.
> > > > > >
> > > > > > Those options are enabled when one adds --enable-burst to the
> > > > > > pre-compilation ./configure of netperf (one doesn't have to
> > > > > > recompile netserver). However, if one is also looking at latency
> > > > > > statistics via the -j option in the top-of-trunk, or simply at the
> > > > > > histogram with --enable-histogram on the ./configure and a verbosity
> > > > > > level of 2 (global -v 2) then one wants the very top of trunk
> > > > > > netperf from:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have constructed a test where I run an un-paced UDP_STREAM test in
> > > > > one guest and a paced omni rr test in another guest at the same time.
> > > >
> > > > Hmm, what is this supposed to measure? Basically each time you run an
> > > > un-paced UDP_STREAM you get some random load on the network.
> > > > You can't tell what it was exactly, only that it was between
> > > > the send and receive throughput.
> > >
> > > Rick mentioned in another email that I messed up my test parameters a bit,
> > > so I will re-run the tests, incorporating his suggestions.
> > >
> > > What I was attempting to measure was the effect of an unpaced UDP_STREAM
> > > on the latency of more moderated traffic. Because I am interested in
> > > what effect an abusive guest has on other guests and how that my be
> > > mitigated.
> > >
> > > Could you suggest some tests that you feel are more appropriate?
> >
> > Yes. To refraze my concern in these terms, besides the malicious guest
> > you have another software in host (netperf) that interferes with
> > the traffic, and it cooperates with the malicious guest.
> > Right?
>
> Yes, that is the scenario in this test.
Yes but I think that you want to put some controlled load on host.
Let's assume that we impove the speed somehow and now you can push more
bytes per second without loss. Result might be a regression in your
test because you let the guest push "as much as it can" and suddenly it
can push more data through. OTOH with packet loss the load on host is
anywhere in between send and receive throughput: there's no easy way to
measure it from netperf: the earlier some buffers overrun, the earlier
the packets get dropped and the less the load on host.
This is why I say that to get a specific
load on host you want to limit the sender
to a specific BW and then either
- make sure packet loss % is close to 0.
- make sure packet loss % is close to 100%.
> > IMO for a malicious guest you would send
> > UDP packets that then get dropped by the host.
> >
> > For example block netperf in host so that
> > it does not consume packets from the socket.
>
> I'm more interested in rate-limiting netperf than blocking it.
Well I mean netperf on host.
> But in any case, do you mean use iptables or tc based on
> classification made by net_cls?
Just to block netperf you can send it SIGSTOP :)
--
MST
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Simon Horman @ 2011-01-23 6:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rick Jones, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110122215742.GC5617@redhat.com>
On Sat, Jan 22, 2011 at 11:57:42PM +0200, Michael S. Tsirkin wrote:
> On Sat, Jan 22, 2011 at 10:11:52AM +1100, Simon Horman wrote:
> > On Fri, Jan 21, 2011 at 11:59:30AM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
> > > > [ Trimmed Eric from CC list as vger was complaining that it is too long ]
> > > >
> > > > On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
> > > > > >So it won't be all that simple to implement well, and before we try,
> > > > > >I'd like to know whether there are applications that are helped
> > > > > >by it. For example, we could try to measure latency at various
> > > > > >pps and see whether the backpressure helps. netperf has -b, -w
> > > > > >flags which might help these measurements.
> > > > >
> > > > > Those options are enabled when one adds --enable-burst to the
> > > > > pre-compilation ./configure of netperf (one doesn't have to
> > > > > recompile netserver). However, if one is also looking at latency
> > > > > statistics via the -j option in the top-of-trunk, or simply at the
> > > > > histogram with --enable-histogram on the ./configure and a verbosity
> > > > > level of 2 (global -v 2) then one wants the very top of trunk
> > > > > netperf from:
> > > >
> > > > Hi,
> > > >
> > > > I have constructed a test where I run an un-paced UDP_STREAM test in
> > > > one guest and a paced omni rr test in another guest at the same time.
> > >
> > > Hmm, what is this supposed to measure? Basically each time you run an
> > > un-paced UDP_STREAM you get some random load on the network.
> > > You can't tell what it was exactly, only that it was between
> > > the send and receive throughput.
> >
> > Rick mentioned in another email that I messed up my test parameters a bit,
> > so I will re-run the tests, incorporating his suggestions.
> >
> > What I was attempting to measure was the effect of an unpaced UDP_STREAM
> > on the latency of more moderated traffic. Because I am interested in
> > what effect an abusive guest has on other guests and how that my be
> > mitigated.
> >
> > Could you suggest some tests that you feel are more appropriate?
>
> Yes. To refraze my concern in these terms, besides the malicious guest
> you have another software in host (netperf) that interferes with
> the traffic, and it cooperates with the malicious guest.
> Right?
Yes, that is the scenario in this test.
> IMO for a malicious guest you would send
> UDP packets that then get dropped by the host.
>
> For example block netperf in host so that
> it does not consume packets from the socket.
I'm more interested in rate-limiting netperf than blocking it.
But in any case, do you mean use iptables or tc based on
classification made by net_cls?
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Michael S. Tsirkin @ 2011-01-22 21:57 UTC (permalink / raw)
To: Simon Horman
Cc: Rick Jones, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110121231149.GI2195@verge.net.au>
On Sat, Jan 22, 2011 at 10:11:52AM +1100, Simon Horman wrote:
> On Fri, Jan 21, 2011 at 11:59:30AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
> > > [ Trimmed Eric from CC list as vger was complaining that it is too long ]
> > >
> > > On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
> > > > >So it won't be all that simple to implement well, and before we try,
> > > > >I'd like to know whether there are applications that are helped
> > > > >by it. For example, we could try to measure latency at various
> > > > >pps and see whether the backpressure helps. netperf has -b, -w
> > > > >flags which might help these measurements.
> > > >
> > > > Those options are enabled when one adds --enable-burst to the
> > > > pre-compilation ./configure of netperf (one doesn't have to
> > > > recompile netserver). However, if one is also looking at latency
> > > > statistics via the -j option in the top-of-trunk, or simply at the
> > > > histogram with --enable-histogram on the ./configure and a verbosity
> > > > level of 2 (global -v 2) then one wants the very top of trunk
> > > > netperf from:
> > >
> > > Hi,
> > >
> > > I have constructed a test where I run an un-paced UDP_STREAM test in
> > > one guest and a paced omni rr test in another guest at the same time.
> >
> > Hmm, what is this supposed to measure? Basically each time you run an
> > un-paced UDP_STREAM you get some random load on the network.
> > You can't tell what it was exactly, only that it was between
> > the send and receive throughput.
>
> Rick mentioned in another email that I messed up my test parameters a bit,
> so I will re-run the tests, incorporating his suggestions.
>
> What I was attempting to measure was the effect of an unpaced UDP_STREAM
> on the latency of more moderated traffic. Because I am interested in
> what effect an abusive guest has on other guests and how that my be
> mitigated.
>
> Could you suggest some tests that you feel are more appropriate?
Yes. To refraze my concern in these terms, besides the malicious guest
you have another software in host (netperf) that interferes with
the traffic, and it cooperates with the malicious guest.
Right?
IMO for a malicious guest you would send
UDP packets that then get dropped by the host.
For example block netperf in host so that
it does not consume packets from the socket.
^ permalink raw reply
* CFP: 2nd International Green Computing Conference (IGCC'11)
From: Ming Zhao @ 2011-01-22 17:59 UTC (permalink / raw)
To: virtualization
Dear Colleague,
On behalf of the Conference Organizing Committee, we would like to
inform you of the:
SECOND INTERNATIONAL GREEN COMPUTING CONFERENCE (IGCC ’11):
Moto: Sustainable Computing and Computing for Sustainability
Orlando, Florida, USA, (The Holiday Inn at Disneyworld) July 25-28,
2011, www.green-conf.org
The Second International Green Computing Conference, technically
cosponsored by IEEE, addresses key issues and topics related to energy
efficiency in computing and promoting environmentally friendly
computer technologies and systems. The conference provides a forum for
discussing, sharing and investigating the state-of-the-art for all
aspects of green computing, which include energy-efficient use of
computers, design of algorithms and systems for
environmentally-friendly computer technologies, and a wide range of
related topics. The conference seeks papers with unpublished material
and previously unsubmitted material pertaining to the design and use
of sustainable hardware and software systems, algorithms, and
applications. The conference will hold forums, workshops, and
tutorials on hot topics related to how the carbon footprint of
computing can be reduced and how computers can contribute to the
environment and overall well-being of the planet.
Topics of interest are:
* Power-aware software
* Configurable and renewable energy
* Code profiling and transformation for power management
* Low power electronics
* Power-aware middleware
* Embedded systems, ASICs and FPGSs
* Power-efficient architectures and chip designs
* Power leakage and dissipation
* Resource management to optimize performance and power
* Power implications for portable and mobile computing
* Runtime systems that assist in power saving
* Power aware networking
* Models for collective optimization of power and performance
* Reliability of Power-aware computers
* Monitoring tools for power and performance
* Use of sensors for climate monitoring
* Algorithms for reduced power, energy and heat
* Smart control for eco-friendly buildings
* Power-aware applications
* Thermal control of data centers
* Static and dynamic data allocation for distributed servers
* Energy recycling
* Efficient circuit design for energy harvesting
* Energy efficient power and cooling infrastructure
* Power efficient cluster and enterprise computing
* Configurable and renewable energy
* Component level power management, e.g., memory, disk.
* Low power electronics
* Power leakage and dissipation
* Embedded systems, ASICs and FPGSs
Review of Manuscripts
All submitted manuscripts will be reviewed by the conference Technical
Committee and evaluated on correctness, originality, technical
strength, significance, quality of presentation, interest and
relevance to the conference scope. Papers must be received by the
submission deadline to be considered for inclusion in the conference.
Best Paper Awards
Awards will be given for best papers in different categories.
Important Dates:
* Submission Deadline: Monday, March 18, 2011, 11:59pm, U.S. Eastern
Daylight Time
* Paper notification: May 13, 2011
* Camera ready papers due: June 6, 2011
The final appearance of the accepted papers in the official conference
proceedings (through IEEE Digital Library) is contingent on two
conditions: (1) that at least one author of an accepted paper
registers for the conference at the time of the submission of the
final manuscript and (2) that one of the authors presents the paper at
the conference in person. Full details of the conference may be found
at the conference website: www.green-conf.org. To directly access
submission please go to
https://www.easychair.org/login.cgi?conf=igcc101
Workshops
Several workshops on related topics will be held in conjunction with
the Green Computing conference.
1. Energy Consumption and Reliability of Storage Systems; Co-Chairs:
Ali Butt, Virginia Tech.; and Chris Gniady, U. of Arizona;
2. Power Measurement and Profiling; Weisong Shi (Wayne State);
3. Thermal Management Dhireesha Kudithipudi, RIT;
4. Low Power System on Chip, Partha Pande, WSU.
Committees
* General Co-Chairs: Ishfaq Ahmad, University of Texas at Arlington,
and Sanjay Ranka, University of Florida.
* Technical Committee: Co-Chairs: Israel Koren, University of
Massachusetts, and Daniel Mosse University of Pittsburgh;
* Members: Tarek Abdelzaher, UIUC; David Albonesi, Cornell; Ahmed
Amer, Santa Clara Univ; Martin Arlitt, HP Labs and University of
Calgary; Hakan Aydin, George Mason Univ; Luca Benini, Univ. of
Bologna; Ricardo Bianchini, Rutgers; John Carter, IBM; Ranveer
Chandra, Microsoft Research; Vince Freeh, NCSU; Rong Ge, Marquette
Univ; Sameh Gobriel, Intel Research; Rajesh Gupta, UCSD; Tohru
Ishihara, Kyushu Univ; Randy Katz, UC Berkeley; Uli Kremer, Rutgers;
C. Mani Krishna, U Mass.; Rakesh Kumar, UIUC; Alvin Lebeck, Duke
University; Yann-Hang Lee, ASU; Julius Leite, UFF/Brazil; Xue Liu,
UNL; Satoshi Matsouka, TITECH-Japan; Rami G. Melhem, University of
Pittsburgh; Avi Mendelson. Microsoft, Israel; Bruce Normad, Lawrence
Berkeley Lab; Lucy Nowell, DOE: Partha Ranganathan, HP Labs; Tajana
Rosing, UCSD; Efi Rotem, Intel:; Anthony Rowe, CMU; Martin Schulz,
LLNL; Ankur Srivastva, University of Maryland; Osman Unsal, BSC,
Barcelona; Shengquan Wang, Michigan; Dakai Zhu, UTSA.
* Workshop Chair: Sanjay Ranka, University of Florida, USA.
* Publication Chair: Saeed Rajput, Nova Southeastern University, USA
* Publicity Co-Chairs: Javier Alonso, Technical University of
Catalonia, Spain; Ming Zhao Florida International University, USA.
* Steering Committee: Behrooz Shirazi (Co-Chair), Washington State
University, USA; Ishfaq Ahmad (Co-Chair), University of Texas at
Arlington, USA; Rajesh Gupta, University of California at San Diego,
USA; Sandeep Gupta, Arizona State University, USA; Ali Hurson,
Missouri University of Science and Technology, USA; Ashfaq Khokhar,
University of Illinois at Chicago, USA; Francis Lau, University of
Hong Kong, China; Sanjay Ranka, University of Florida, USA.
Keynote Speaker: David Culler, UC Berkeley.
We look forward to receiving your submission(s), and hope you will be
able to join us in Orlando in July.
Sincerely,
IGCC’11 Organizing Committee
^ permalink raw reply
* Re: [PATCH 2/3] kvm hypervisor : Add hypercalls to support pv-ticketlock
From: Rik van Riel @ 2011-01-22 14:53 UTC (permalink / raw)
To: vatsa
Cc: Xen-devel, Mathieu Desnoyers, Nick Piggin, kvm, Peter Zijlstra,
Linux Kernel Mailing List, Jan Beulich, Eric Dumazet,
Jeremy Fitzhardinge, suzuki, Avi Kivity, H. Peter Anvin,
Américo Wang, Linux Virtualization
In-Reply-To: <20110122061417.GA7258@linux.vnet.ibm.com>
On 01/22/2011 01:14 AM, Srivatsa Vaddagiri wrote:
> Also it may be possible for the pv-ticketlocks to track owning vcpu and make use
> of a yield-to interface as further optimization to avoid the
> "others-get-more-time" problem, but Peterz rightly pointed that PI would be a
> better solution there than yield-to. So overall IMO kvm_vcpu_on_spin+yield_to
> could be the best solution for unmodified guests, while paravirtualized
> ticketlocks + some sort of PI would be a better solution where we have the
> luxury of modifying guest sources!
Agreed, for unmodified guests (which is what people will mostly be
running for the next couple of years), we have little choice but
to use PLE + kvm_vcpu_on_spin + yield_to.
The main question that remains is whether the PV ticketlocks are
a large enough improvement to also merge those. I expect they
will be, and we'll see so in the benchmark numbers.
--
All rights reversed
^ permalink raw reply
* Re: [PATCH 2/3] kvm hypervisor : Add hypercalls to support pv-ticketlock
From: Srivatsa Vaddagiri @ 2011-01-22 6:14 UTC (permalink / raw)
To: Rik van Riel
Cc: Xen-devel, Mathieu Desnoyers, Nick Piggin, kvm, Peter Zijlstra,
Linux Kernel Mailing List, Jan Beulich, Eric Dumazet,
Jeremy Fitzhardinge, suzuki, Avi Kivity, H. Peter Anvin,
Américo Wang, Linux Virtualization
In-Reply-To: <4D399CBD.10506@redhat.com>
On Fri, Jan 21, 2011 at 09:48:29AM -0500, Rik van Riel wrote:
> >>Why? If a VCPU can't make progress because its waiting for some
> >>resource, then why not schedule something else instead?
> >
> >In the process, "something else" can get more share of cpu resource than its
> >entitled to and that's where I was bit concerned. I guess one could
> >employ hard-limits to cap "something else's" bandwidth where it is of real
> >concern (like clouds).
>
> I'd like to think I fixed those things in my yield_task_fair +
> yield_to + kvm_vcpu_on_spin patch series from yesterday.
Speaking of the spinlock-in-virtualized-environment problem as whole, IMHO
I don't think that kvm_vcpu_on_spin + yield changes will provide the best
results, especially where ticketlocks are involved and they are paravirtualized
in a manner being discussed in this thread. An important focus of pv-ticketlocks
is to reduce the lock _acquisition_ time by ensuring that the next-in-line
vcpu gets to run asap when a ticket lock is released. With the way
kvm_vcpu_on_spin+yield_to is implemented, I don't see how we can provide the
best lock acquisition times for threads. It would be nice though to compare
the two approaches (kvm_vcpu_on_spin optimization and the pv-ticketlock scheme)
to get some real-world numbers. I unfortunately don't have access to a PLE
capable hardware which is required to test your kvm_vcpu_on_spin changes?
Also it may be possible for the pv-ticketlocks to track owning vcpu and make use
of a yield-to interface as further optimization to avoid the
"others-get-more-time" problem, but Peterz rightly pointed that PI would be a
better solution there than yield-to. So overall IMO kvm_vcpu_on_spin+yield_to
could be the best solution for unmodified guests, while paravirtualized
ticketlocks + some sort of PI would be a better solution where we have the
luxury of modifying guest sources!
- vatsa
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Simon Horman @ 2011-01-21 23:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rick Jones, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110121095929.GE26070@redhat.com>
On Fri, Jan 21, 2011 at 11:59:30AM +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
> > [ Trimmed Eric from CC list as vger was complaining that it is too long ]
> >
> > On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
> > > >So it won't be all that simple to implement well, and before we try,
> > > >I'd like to know whether there are applications that are helped
> > > >by it. For example, we could try to measure latency at various
> > > >pps and see whether the backpressure helps. netperf has -b, -w
> > > >flags which might help these measurements.
> > >
> > > Those options are enabled when one adds --enable-burst to the
> > > pre-compilation ./configure of netperf (one doesn't have to
> > > recompile netserver). However, if one is also looking at latency
> > > statistics via the -j option in the top-of-trunk, or simply at the
> > > histogram with --enable-histogram on the ./configure and a verbosity
> > > level of 2 (global -v 2) then one wants the very top of trunk
> > > netperf from:
> >
> > Hi,
> >
> > I have constructed a test where I run an un-paced UDP_STREAM test in
> > one guest and a paced omni rr test in another guest at the same time.
>
> Hmm, what is this supposed to measure? Basically each time you run an
> un-paced UDP_STREAM you get some random load on the network.
> You can't tell what it was exactly, only that it was between
> the send and receive throughput.
Rick mentioned in another email that I messed up my test parameters a bit,
so I will re-run the tests, incorporating his suggestions.
What I was attempting to measure was the effect of an unpaced UDP_STREAM
on the latency of more moderated traffic. Because I am interested in
what effect an abusive guest has on other guests and how that my be
mitigated.
Could you suggest some tests that you feel are more appropriate?
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Rick Jones @ 2011-01-21 18:04 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Simon Horman, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110121095929.GE26070@redhat.com>
>>I have constructed a test where I run an un-paced UDP_STREAM test in
>>one guest and a paced omni rr test in another guest at the same time.
>
>
> Hmm, what is this supposed to measure? Basically each time you run an
> un-paced UDP_STREAM you get some random load on the network.
Well, if the netperf is (effectively) pinned to a given CPU, presumably it would
be trying to generate UDP datagrams at the same rate each time. Indeed though,
no guarantee that rate would consistently get through each time.
But then, that is where one can use the confidence intervals options to get an
idea by how much the rate varied.
rick jones
^ permalink raw reply
* Re: [PATCH 2/3] kvm hypervisor : Add hypercalls to support pv-ticketlock
From: Rik van Riel @ 2011-01-21 14:48 UTC (permalink / raw)
To: vatsa
Cc: Xen-devel, Mathieu Desnoyers, Nick Piggin, kvm, Peter Zijlstra,
Linux Kernel Mailing List, Jan Beulich, Eric Dumazet,
Jeremy Fitzhardinge, suzuki, Avi Kivity, H. Peter Anvin,
Américo Wang, Linux Virtualization
In-Reply-To: <20110121140208.GA13609@linux.vnet.ibm.com>
On 01/21/2011 09:02 AM, Srivatsa Vaddagiri wrote:
> On Thu, Jan 20, 2011 at 09:56:27AM -0800, Jeremy Fitzhardinge wrote:
>>> The key here is not to
>>> sleep when waiting for locks (as implemented by current patch-series, which can
>>> put other VMs at an advantage by giving them more time than they are entitled
>>> to)
>>
>> Why? If a VCPU can't make progress because its waiting for some
>> resource, then why not schedule something else instead?
>
> In the process, "something else" can get more share of cpu resource than its
> entitled to and that's where I was bit concerned. I guess one could
> employ hard-limits to cap "something else's" bandwidth where it is of real
> concern (like clouds).
I'd like to think I fixed those things in my yield_task_fair +
yield_to + kvm_vcpu_on_spin patch series from yesterday.
https://lkml.org/lkml/2011/1/20/403
--
All rights reversed
^ permalink raw reply
* Re: [PATCH 2/3] kvm hypervisor : Add hypercalls to support pv-ticketlock
From: Srivatsa Vaddagiri @ 2011-01-21 14:02 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Xen-devel, Mathieu Desnoyers, Nick Piggin, kvm, Peter Zijlstra,
Linux Kernel Mailing List, Jan Beulich, Eric Dumazet,
Jeremy Fitzhardinge, suzuki, Avi Kivity, H. Peter Anvin,
Américo Wang, Linux Virtualization
In-Reply-To: <4D38774B.6070704@goop.org>
On Thu, Jan 20, 2011 at 09:56:27AM -0800, Jeremy Fitzhardinge wrote:
> > The key here is not to
> > sleep when waiting for locks (as implemented by current patch-series, which can
> > put other VMs at an advantage by giving them more time than they are entitled
> > to)
>
> Why? If a VCPU can't make progress because its waiting for some
> resource, then why not schedule something else instead?
In the process, "something else" can get more share of cpu resource than its
entitled to and that's where I was bit concerned. I guess one could
employ hard-limits to cap "something else's" bandwidth where it is of real
concern (like clouds).
> Presumably when
> the VCPU does become runnable, the scheduler will credit its previous
> blocked state and let it run in preference to something else.
which may not be sufficient for it to gain back bandwidth lost while blocked
(speaking of mainline scheduler atleast).
> > Is there a way we can dynamically expand the size of lock only upon contention
> > to include additional information like owning vcpu? Have the lock point to a
> > per-cpu area upon contention where additional details can be stored perhaps?
>
> As soon as you add a pointer to the lock, you're increasing its size.
I didn't really mean to expand size statically. Rather have some bits of the
lock word store pointer to a per-cpu area when there is contention (somewhat
similar to how bits of rt_mutex.owner are used). I haven't thought thr' this in
detail to see if that is possible though.
- vatsa
^ permalink raw reply
* SNAPI2011 deadline in 1 week (7th IEEE International Workshop on Storage Network Architecture and Parallel I/Os)
From: Ming Zhao @ 2011-01-21 12:04 UTC (permalink / raw)
To: virtualization
[Just a gentle reminder that the deadline is only one week away]
========================================================================
Call for Papers
7th IEEE International Workshop on
Storage Network Architecture and Parallel I/Os
(SNAPI 2011)
http://snapi2011.cis.fiu.edu
May 25, 2011 Denver, Colorado, USA
In conjunction with the 27th IEEE Conference on
Mass Storage Systems and Technologies (MSST 2011)
========================================================================
SCOPE:
------
The 7th IEEE Storage Networking Architecture and Parallel I/O (SNAPI
2011) Workshop aims to highlight the latest research in the
architecture, design, implementation, and evaluation of local and
networked storage and parallel I/O systems. The workshop is co-located
with the 27th IEEE Conference on Mass Storage Systems and Technologies
(MSST2011) that features a full week dedicated to "all things storage".
The SNAPI 2011 workshop, held in the middle of the MSST week, will
feature a full day of technical papers that showcase the latest work
from the academia, the labs, and the industry.
This year we would like to encourage a variety of submissions including
novel idea papers, real system experience papers, as well as analysis
and evaluation papers. Topics of interest include, but are not limited
to:
* Caching, replication, and consistency
* Energy-efficient storage
* Evaluation of networked storage architectures
* Experiences with real systems
* File and block based network storage
* Integration and evaluation of emerging storage technology
* I/O quality of service
* New abstractions/protocols for data, storage, and I/O
* Parallel I/O
* Performance, scalability, and manageability of networked storage
* SSD-based storage architectures and tiered storage
* Storage device and workload characterization
* Storage networking
* Storage reliability and failure management
* Storage virtualization
* Thin provisioning, consolidation, compression, and deduplication
* Wide-area networked storage
SUBMISSIONS INSTRUCTIONS:
-------------------------
Submissions should not exceed 8 single-space pages including all text,
figures, and references. Submissions must be typeset as double-column
text, using no less than 10 pt font, and using a text block that does
not exceed 6.5" width and 9" height.
The reviewing is double-blind. Authors must not be identified in the
submission either directly or indirectly. Please be careful so as to not
refer to your own work in the first person or leak authorship in any way
within the text of the paper. Reviewing will be performed by the members
of the SNAPI’11 Program Committee. Each paper will receive at least
three reviews from members of the Program Committee.
The final version of the paper prepared after incorporating reviewer
feedback should be submitted by April 1st, 2011. At least one author of
each accepted paper will be expected to attend the workshop and present
their work in a 25 minute talk.
BEST PAPER AWARD:
-----------------
Authors of the best paper, chosen by the Program Committee, will be
presented an award at the workshop.
Important dates:
----------------
* Full paper submission: January 28, 2011
* Notification of acceptance: March 4, 2011
* Final manuscripts due: April 1, 2011
* Workshop: May 25, 2011
Organization:
-------------
* Program Chair:
o Raju Rangaswami, Florida International University
* Program Committee:
o Angelos Bilas, FORTH and University of Crete
o Randal Burns, Johns Hopkins University
o Dan Feng, Huazhong University of Science and Technology
o Dirk Grunwald, University of Colorado, Boulder
o Ajay Gulati, VMware
o Ron Oldfield, Sandia National Laboratory
o Vijayan Prabhakaran, Microsoft Research
o Himabindu Pucha, IBM Research - Almaden
o A. L. Narasimha Reddy, Texas A&M University
o Alma Riska, College of William and Mary
o Philip Roth, Oak Ridge National Laboratory
o Jiri Schindler, NetApp
o Rajeev Thakur, Argonne National Laboratory
o Bhuvan Urgaonkar, Pennsylvania State University
o Youjip Won, Hanyang University
o Ming Zhao, Florida International University
* Web and Publicity Chair:
o Ming Zhao, Florida International University
* Steering Committee:
o Qing Yang, University of Rhode Island
o Hong Jiang, University of Nebraska-Lincoln
o Xubin He, Tennessee Tech University
SPONSORSHIP:
------------
IEEE Mass Storage Systems Technical Committee (MSSTC)
Information:
------------
* SNAPI 2001 Web: http://snapi2011.cis.fiu.edu
* MSST 2011 Web: http://storageconference.org
* Email: snapi2011@cis.fiu.edu
--
Ming Zhao, Assistant Professor
School of Computing and Information Sciences
Florida International University
Tel: (305) 348-2034, Fax: (305) 348-3549
Web: http://visa.cs.fiu.edu/ming
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Michael S. Tsirkin @ 2011-01-21 9:59 UTC (permalink / raw)
To: Simon Horman
Cc: Rick Jones, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110120083727.GA1807@verge.net.au>
On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
> [ Trimmed Eric from CC list as vger was complaining that it is too long ]
>
> On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
> > >So it won't be all that simple to implement well, and before we try,
> > >I'd like to know whether there are applications that are helped
> > >by it. For example, we could try to measure latency at various
> > >pps and see whether the backpressure helps. netperf has -b, -w
> > >flags which might help these measurements.
> >
> > Those options are enabled when one adds --enable-burst to the
> > pre-compilation ./configure of netperf (one doesn't have to
> > recompile netserver). However, if one is also looking at latency
> > statistics via the -j option in the top-of-trunk, or simply at the
> > histogram with --enable-histogram on the ./configure and a verbosity
> > level of 2 (global -v 2) then one wants the very top of trunk
> > netperf from:
>
> Hi,
>
> I have constructed a test where I run an un-paced UDP_STREAM test in
> one guest and a paced omni rr test in another guest at the same time.
Hmm, what is this supposed to measure? Basically each time you run an
un-paced UDP_STREAM you get some random load on the network.
You can't tell what it was exactly, only that it was between
the send and receive throughput.
> Breifly I get the following results from the omni test..
>
> 1. Omni test only: MEAN_LATENCY=272.00
> 2. Omni and stream test: MEAN_LATENCY=3423.00
> 3. cpu and net_cls group: MEAN_LATENCY=493.00
> As per 2 plus cgoups are created for each guest
> and guest tasks added to the groups
> 4. 100Mbit/s class: MEAN_LATENCY=273.00
> As per 3 plus the net_cls groups each have a 100MBit/s HTB class
> 5. cpu.shares=128: MEAN_LATENCY=652.00
> As per 4 plus the cpu groups have cpu.shares set to 128
> 6. Busy CPUS: MEAN_LATENCY=15126.00
> As per 5 but the CPUs are made busy using a simple shell while loop
>
> There is a bit of noise in the results as the two netperf invocations
> aren't started at exactly the same moment
>
> For reference, my netperf invocations are:
> netperf -c -C -t UDP_STREAM -H 172.17.60.216 -l 12
> netperf.omni -p 12866 -D -c -C -H 172.17.60.216 -t omni -j -v 2 -- -r 1 -d rr -k foo -b 1 -w 200 -m 200
>
> foo contains
> PROTOCOL
> THROUGHPUT,THROUGHPUT_UNITS
> LOCAL_SEND_THROUGHPUT
> LOCAL_RECV_THROUGHPUT
> REMOTE_SEND_THROUGHPUT
> REMOTE_RECV_THROUGHPUT
> RT_LATENCY,MIN_LATENCY,MEAN_LATENCY,MAX_LATENCY
> P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY
> LOCAL_CPU_UTIL,REMOTE_CPU_UTIL
^ permalink raw reply
* Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
From: Andrew Morton @ 2011-01-21 8:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-fbdev, Greg KH, Lars-Peter Clausen, James Hogan,
David Airlie, Daniel Vetter, linux-omap, Jesse Barnes,
James E.J. Bottomley, David S. Miller, Paul Mackerras,
Liam Girdwood, Kyle McMartin, Jiri Slaby, Thomas Gleixner,
Caglar Akyuz, devel, Alberto Panizzo, Phil Edworthy, xen-devel,
Russell King, Kuninor
In-Reply-To: <AANLkTinN2+pNGk1hwrcMhH5qDNZK=Egrw7P6c-cdJTmH@mail.gmail.com>
On Fri, 21 Jan 2011 09:10:06 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> include/linux/mutex.h:
>
> /*
> * NOTE: mutex_trylock() follows the spin_trylock() convention,
> * not the down_trylock() convention!
> *
> * Returns 1 if the mutex has been acquired successfully, and 0 on contention.
> */
> extern int mutex_trylock(struct mutex *lock);
>
> So that's why the return value was inverted (when treating it as a boolean).
> I can understand that.
>
> However:
>
> +/**
> + * console_trylock - try to lock the console system for exclusive use.
> + *
> + * Tried to acquire a lock which guarantees that the caller has
> + * exclusive access to the console system and the console_drivers list.
> + *
> + * returns -1 on success, and 0 on failure to acquire the lock.
> + */
> +int console_trylock(void)
>
> So this one returns -1 on success, not 1? Why?
Yup. All callers just test for non-zero, so...
--- a/kernel/printk.c~change-acquire-release_console_sem-to-console_lock-unlock-fix-2
+++ a/kernel/printk.c
@@ -1058,7 +1058,7 @@ EXPORT_SYMBOL(console_lock);
* Tried to acquire a lock which guarantees that the caller has
* exclusive access to the console system and the console_drivers list.
*
- * returns -1 on success, and 0 on failure to acquire the lock.
+ * returns 1 on success, and 0 on failure to acquire the lock.
*/
int console_trylock(void)
{
@@ -1070,7 +1070,7 @@ int console_trylock(void)
}
console_locked = 1;
console_may_schedule = 0;
- return -1;
+ return 1;
}
EXPORT_SYMBOL(console_trylock);
_
^ permalink raw reply
* Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
From: Geert Uytterhoeven @ 2011-01-21 8:10 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev, Greg KH, Lars-Peter Clausen, James Hogan,
David Airlie, Daniel Vetter, linux-omap, Jesse Barnes,
James E.J. Bottomley, David S. Miller, Paul Mackerras,
Liam Girdwood, Kyle McMartin, Jiri Slaby, Thomas Gleixner,
Caglar Akyuz, devel, Alberto Panizzo, Phil Edworthy, xen-devel,
Russell King, Kuninor
In-Reply-To: <20110120123507.ac89c034.akpm@linux-foundation.org>
On Thu, Jan 20, 2011 at 21:35, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 20 Jan 2011 17:55:02 +0100
> torbenh <torbenh@gmx.de> wrote:
>
>> On Thu, Jan 20, 2011 at 08:34:48AM -0800, Greg KH wrote:
>> > On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote:
>> > > the -rt patches change the console_semaphore to console_mutex.
>> > > so a quite large chunk of the patches changes all
>> > > acquire/release_console_sem() to acquire/release_console_mutex()
>> >
>> > Why not just change the functionality of the existing function to be a
>> > mutex in the rt patches, instead of having to rename it everywhere?
>>
>> i hope that Thomas already did this in his upcoming -rt series.
>>
>> >
>> > > this commit makes things use more neutral function names
>> > > which dont make implications about the underlying lock.
>> > >
>> > > the only real change is the return value of console_trylock
>> > > which is inverted from try_acquire_console_sem()
>> > >
>> > > Signed-off-by: Torben Hohn <torbenh@gmx.de>
>> > > CC: Thomas Gleixner <tglx@tglx.de>
>> >
>> > I don't mind this rename, but is it really going to help anything out?
>> > What's the odds of the -rt portion of this patch ever making it to
>> > mainline?
>>
>> the -rt portion only changes the semaphore to a mutex.
>> since the console_sem is used with mutex semantics, i dont see any
>> reason, not to merge that portion too.
>>
>> i am just trying to shrink the -rt patch to make it more maintanable :)
>>
>
> Yeah, I think it's a better name and if we can indeed switch that
> semaphore to a mutex then that's a good thing to do.
include/linux/mutex.h:
/*
* NOTE: mutex_trylock() follows the spin_trylock() convention,
* not the down_trylock() convention!
*
* Returns 1 if the mutex has been acquired successfully, and 0 on contention.
*/
extern int mutex_trylock(struct mutex *lock);
So that's why the return value was inverted (when treating it as a boolean).
I can understand that.
However:
+/**
+ * console_trylock - try to lock the console system for exclusive use.
+ *
+ * Tried to acquire a lock which guarantees that the caller has
+ * exclusive access to the console system and the console_drivers list.
+ *
+ * returns -1 on success, and 0 on failure to acquire the lock.
+ */
+int console_trylock(void)
So this one returns -1 on success, not 1? Why?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Rick Jones @ 2011-01-21 2:30 UTC (permalink / raw)
To: Simon Horman
Cc: Michael S. Tsirkin, Jesse Gross, Rusty Russell, virtualization,
dev, virtualization, netdev, kvm
In-Reply-To: <20110120083727.GA1807@verge.net.au>
Simon Horman wrote:
> [ Trimmed Eric from CC list as vger was complaining that it is too long ]
>...
> I have constructed a test where I run an un-paced UDP_STREAM test in
> one guest and a paced omni rr test in another guest at the same time.
> Breifly I get the following results from the omni test..
>
>...
>
> There is a bit of noise in the results as the two netperf invocations
> aren't started at exactly the same moment
>
> For reference, my netperf invocations are:
> netperf -c -C -t UDP_STREAM -H 172.17.60.216 -l 12
> netperf.omni -p 12866 -D -c -C -H 172.17.60.216 -t omni -j -v 2 -- -r 1 -d rr -k foo -b 1 -w 200 -m 200
Since the -b and -w are in the test-specific portion, this test was not actually
paced. The -w will have been ignored entirely (IIRC) and the -b will have
attempted to set the "burst" size of a --enable-burst ./configured netperf. If
netperf was ./configured that way, it will have had two rr transactions in
flight at one time - the "regular" one and then the one additional from the -b
option. If netperf was not ./configured with --enable-burst then a warning
message should have been emitted.
Also, I am guessing you wanted TCP_NODELAY set, and that is -D but not a global
-D. I'm reasonably confident the -m 200 will have been ignored, but it would be
best to drop it. So, I think your second line needs to be:
netperf.omni -p 12866 -c -C -H 172.17.60.216 -t omni -j -v 2 -b 1 -w 200 -- -r
1 -d rr -k foo -D
If you want the request and response sizes to be 200 bytes, use -r 200
(test-specific).
Also, if you ./configure with --enable-omni first, that netserver will
understand both omni and non-omni tests at the same time and you don't have to
have a second netserver on a different control port. You can also go-in to
config.h after the ./configure and unset WANT_MIGRATION and then UDP_STREAM in
netperf will be the "true" classic UDP_STREAM code rather than the migrated to
omni path.
> foo contains
> PROTOCOL
> THROUGHPUT,THROUGHPUT_UNITS
> LOCAL_SEND_THROUGHPUT
> LOCAL_RECV_THROUGHPUT
> REMOTE_SEND_THROUGHPUT
> REMOTE_RECV_THROUGHPUT
> RT_LATENCY,MIN_LATENCY,MEAN_LATENCY,MAX_LATENCY
> P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY
> LOCAL_CPU_UTIL,REMOTE_CPU_UTIL
As the -k file parsing option didn't care until recently (within the hour or
so), I think it didn't matter that you had more than four lines (assuming that
is a verbatim cat of foo). However, if you pull the *current* top of trunk, it
will probably start to care - I'm in the midst of adding support for "direct
output selection" in the -k, -o and -O options and also cleaning-up the omni
printing code to the point where there is only the one routing parsing the
output selection file. Currently that is the one for "human" output, which has
a four line restriction. I will try to make it smarter as I go.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
From: Andrew Morton @ 2011-01-20 20:35 UTC (permalink / raw)
To: torbenh
Cc: xen-devel, Kees Cook, linux-fbdev, Mark Brown, Sascha Hauer,
James Hogan, David Airlie, Benjamin Herrenschmidt, Jesse Barnes,
James Morris, Grant Likely, Paul Mackerras, linux-parisc,
Magnus Damm, Jiri Slaby, Dan Williams, devel, Guy Martin,
Kuninori Morimoto, Jeremy Fitzhardinge
In-Reply-To: <20110120165502.GA10832@siel.b>
On Thu, 20 Jan 2011 17:55:02 +0100
torbenh <torbenh@gmx.de> wrote:
> On Thu, Jan 20, 2011 at 08:34:48AM -0800, Greg KH wrote:
> > On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote:
> > > the -rt patches change the console_semaphore to console_mutex.
> > > so a quite large chunk of the patches changes all
> > > acquire/release_console_sem() to acquire/release_console_mutex()
> >
> > Why not just change the functionality of the existing function to be a
> > mutex in the rt patches, instead of having to rename it everywhere?
>
> i hope that Thomas already did this in his upcoming -rt series.
>
> >
> > > this commit makes things use more neutral function names
> > > which dont make implications about the underlying lock.
> > >
> > > the only real change is the return value of console_trylock
> > > which is inverted from try_acquire_console_sem()
> > >
> > > Signed-off-by: Torben Hohn <torbenh@gmx.de>
> > > CC: Thomas Gleixner <tglx@tglx.de>
> >
> > I don't mind this rename, but is it really going to help anything out?
> > What's the odds of the -rt portion of this patch ever making it to
> > mainline?
>
> the -rt portion only changes the semaphore to a mutex.
> since the console_sem is used with mutex semantics, i dont see any
> reason, not to merge that portion too.
>
> i am just trying to shrink the -rt patch to make it more maintanable :)
>
Yeah, I think it's a better name and if we can indeed switch that
semaphore to a mutex then that's a good thing to do.
^ permalink raw reply
* Re: [PATCH 2/3] kvm hypervisor : Add hypercalls to support pv-ticketlock
From: Jeremy Fitzhardinge @ 2011-01-20 17:56 UTC (permalink / raw)
To: vatsa
Cc: Xen-devel, Mathieu Desnoyers, Nick Piggin, kvm, Peter Zijlstra,
Linux Kernel Mailing List, Jan Beulich, Eric Dumazet,
Jeremy Fitzhardinge, suzuki, Avi Kivity, H. Peter Anvin,
Américo Wang, Linux Virtualization
In-Reply-To: <20110120115958.GB11177@linux.vnet.ibm.com>
On 01/20/2011 03:59 AM, Srivatsa Vaddagiri wrote:
>> At least in the Xen code, a current owner isn't very useful, because we
>> need the current owner to kick the *next* owner to life at release time,
>> which we can't do without some structure recording which ticket belongs
>> to which cpu.
> If we had a yield-to [1] sort of interface _and_ information on which vcpu
> owns a lock, then lock-spinners can yield-to the owning vcpu, while the
> unlocking vcpu can yield-to the next-vcpu-in-waiting.
Perhaps, but the core problem is how to find "next-vcpu-in-waiting"
efficiently. Once you have that info, there's a number of things you
can usefully do with it.
> The key here is not to
> sleep when waiting for locks (as implemented by current patch-series, which can
> put other VMs at an advantage by giving them more time than they are entitled
> to)
Why? If a VCPU can't make progress because its waiting for some
resource, then why not schedule something else instead? Presumably when
the VCPU does become runnable, the scheduler will credit its previous
blocked state and let it run in preference to something else.
> and also to ensure that lock-owner as well as the next-in-line lock-owner
> are not unduly made to wait for cpu.
>
> Is there a way we can dynamically expand the size of lock only upon contention
> to include additional information like owning vcpu? Have the lock point to a
> per-cpu area upon contention where additional details can be stored perhaps?
As soon as you add a pointer to the lock, you're increasing its size.
If we had a pointer in there already, then all of this would be moot.
If auxiliary per-lock is uncommon, then using a hash keyed on lock
address would be one way to do it.
J
^ permalink raw reply
* Re: [PATCH 2/3] kvm hypervisor : Add hypercalls to support pv-ticketlock
From: Jeremy Fitzhardinge @ 2011-01-20 17:49 UTC (permalink / raw)
To: vatsa
Cc: Xen-devel, Mathieu Desnoyers, Nick Piggin, kvm, Peter Zijlstra,
Linux Kernel Mailing List, Jan Beulich, Eric Dumazet,
Jeremy Fitzhardinge, suzuki, Avi Kivity, H. Peter Anvin,
Américo Wang, Linux Virtualization
In-Reply-To: <20110120114246.GA11177@linux.vnet.ibm.com>
On 01/20/2011 03:42 AM, Srivatsa Vaddagiri wrote:
> On Wed, Jan 19, 2011 at 10:53:52AM -0800, Jeremy Fitzhardinge wrote:
>>> The reason for wanting this should be clear I guess, it allows PI.
>> Well, if we can expand the spinlock to include an owner, then all this
>> becomes moot...
> How so? Having an owner will not eliminate the need for pv-ticketlocks
> afaict. We still need a mechanism to reduce latency in scheduling the next
> thread-in-waiting, which is achieved by your patches.
No, sorry, I should have been clearer. I meant that going to the effort
of not increasing the lock size to record "in slowpath" state.
J
^ permalink raw reply
* Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
From: torbenh @ 2011-01-20 16:55 UTC (permalink / raw)
To: Greg KH
Cc: xen-devel, Kees Cook, linux-fbdev, Sascha Hauer, James Hogan,
David Airlie, Benjamin Herrenschmidt, Jesse Barnes, James Morris,
Grant Likely, Paul Mackerras, linux-parisc, Magnus Damm,
Jiri Slaby, Dan Williams, devel, Guy Martin, Kuninori Morimoto,
Jeremy Fitzhardinge, Russell King, Thomas Gleixner, Wu
In-Reply-To: <20110120163448.GA30588@suse.de>
On Thu, Jan 20, 2011 at 08:34:48AM -0800, Greg KH wrote:
> On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote:
> > the -rt patches change the console_semaphore to console_mutex.
> > so a quite large chunk of the patches changes all
> > acquire/release_console_sem() to acquire/release_console_mutex()
>
> Why not just change the functionality of the existing function to be a
> mutex in the rt patches, instead of having to rename it everywhere?
i hope that Thomas already did this in his upcoming -rt series.
>
> > this commit makes things use more neutral function names
> > which dont make implications about the underlying lock.
> >
> > the only real change is the return value of console_trylock
> > which is inverted from try_acquire_console_sem()
> >
> > Signed-off-by: Torben Hohn <torbenh@gmx.de>
> > CC: Thomas Gleixner <tglx@tglx.de>
>
> I don't mind this rename, but is it really going to help anything out?
> What's the odds of the -rt portion of this patch ever making it to
> mainline?
the -rt portion only changes the semaphore to a mutex.
since the console_sem is used with mutex semantics, i dont see any
reason, not to merge that portion too.
i am just trying to shrink the -rt patch to make it more maintanable :)
>
> thanks,
>
> greg k-h
--
torben Hohn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox