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 te
[ 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
On Thu, 20 Jan 2011 17:55:02 +0100
torbenh 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 al
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_conso
Michael S. Tsirkin wrote:
> On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
>
>>PS - the enhanced latency statistics from -j are only available in
>>the "omni" version of the TCP_RR test. To get that add a
>>--enable-omni to the ./configure - and in this case both netperf and
>>netser
> 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 m
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 w
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? Havi
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
On Thu, Jan 20, 2011 at 02:41:46PM +0100, Peter Zijlstra wrote:
> On Thu, 2011-01-20 at 17:29 +0530, Srivatsa Vaddagiri wrote:
> >
> > 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,
>
> and then I'd nak
On Thu, 2011-01-20 at 17:29 +0530, Srivatsa Vaddagiri wrote:
>
> 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,
and then I'd nak it for being stupid ;-)
really, yield*() is retarded, never even consider
On Wed, Jan 19, 2011 at 10:53:52AM -0800, Jeremy Fitzhardinge wrote:
> > I didn't really read the patch, and I totally forgot everything from
> > when I looked at the Xen series, but does the Xen/KVM hypercall
> > interface for this include the vcpu to await the kick from?
> >
> > My guess is not,
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-ticke
The following changes since commit 8a335bc631ac9c43675821580c26ebf95a3044ba:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6
(2011-01-16 15:06:43 -0800)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/g
>>> On 19.01.11 at 19:55, Jeremy Fitzhardinge wrote:
> On 01/19/2011 10:39 AM, Srivatsa Vaddagiri wrote:
>> I have tested quite extensively with booting a 16-vcpu guest (on a 16-pcpu
> host)
>> and running kernel compine (with 32-threads). Without this patch, I had
>> difficulty booting/shutting-
15 matches
Mail list logo