[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4727DC88.2020803@goop.org>
Date: Tue, 30 Oct 2007 18:38:16 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: tgh <wwwwww4187@...a.com.cn>
CC: Xen-devel <xen-devel@...ts.xensource.com>,
Jeremy Fitzhardinge <jeremy@...source.com>,
lkml <linux-kernel@...r.kernel.org>, Andi Kleen <ak@...e.de>,
Chris Wright <chrisw@...s-sol.org>,
Andrew Morton <akpm@...ux-foundation.com>
Subject: Re: [Xen-devel] [patch 30/44] xen: Add support for preemption
tgh wrote:
> Thank for your reply
> and I still have several questions
>
>> Yes, that's the normal mode of operation. The hypervisor will timeslice
>> multiple vcpus onto a single vcpu.
>>
>>
> that is ,the VM could be preempted by xen,and could xen hypervisor also
> be preempted to reschedule other vm or xen kernel thread?and are there
> the counterpart abstractions in xen for kernel thread in linux?
>
Yes, a vcpu in Xen is the same as a task in the kernel. In the same way
the kernel multiplexes multiple tasks onto your cpu(s), Xen multiplexes
multiple vcpus onto your cpu(s). This isn't directly visible to the
guest kernel, in the same way that user processes can't generally
observe timeslicing.
>> This patch doesn't relate to that; it's whether a Xen Linux guest's
>> kernel can be preempted to reschedule processes while running under Xen.
>>
>>
> that is ,the patch makes the guest's kernel, rather than xen, be able to
> be preempted ,is it right?
>
Yes. Previous to that change, kernel preemption was disabled when
compiling Xen support in.
J
-
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