I believe the patch is still necessary, since we still need to guarantee
that a vcpu's tsc is monotonous. I think there are three issues to be
addressed:
1. The majority of intel machines don't need the offset adjustment since
they already have a constant rate tsc that is synchronized
For example,
1 rdtsc() is invoked on CPU0
2 process is migrated to CPU1, and rdtsc() is invoked on CPU1
3 if TSC on CPU1 is slower than TSC on CPU0, can kernel guarantee
that the second rdtsc() doesn't return a value smaller than the one
returned by the first rdtsc()?
Thanks,
Forrest
Sorry for reposting it.
For example,
1 rdtsc() is invoked on CPU0
2 process is migrated to CPU1, and rdtsc() is invoked on CPU1
3 if TSC on CPU1 is slower than TSC on CPU0, can kernel guarantee
that the second rdtsc() doesn't return a value smaller than the one
returned by the first rdtsc()?
On Fri, 2008-02-29 at 16:55 +0800, Zhao Forrest wrote:
Sorry for reposting it.
For example,
1 rdtsc() is invoked on CPU0
2 process is migrated to CPU1, and rdtsc() is invoked on CPU1
3 if TSC on CPU1 is slower than TSC on CPU0, can kernel guarantee
that the second rdtsc() doesn't return a
Hello all,
I've implemented a block device which throttles block I/O bandwidth,
which I called dm-ioband, and been trying to throttle I/O bandwidth on
KVM environment. But unfortunately it doesn't work well, the number of
issued I/Os is not according to the bandwidth setting.
On the other hand,
Zhao, Yunfeng wrote:
Hi, all,
This is today's KVM test result against kvm.git
4a7f582a07e14763ee4714b681e98b3b134d1d46 and kvm-userspace.git
bc6db37817ce749dcc88fbc761a36bb8df5cf60a.
LTP and kernel build test on pae linux guest are failed,
because these case boot guests with smp 2.6.9
On Thu, Feb 28, 2008 at 04:59:59PM -0800, Christoph Lameter wrote:
And thus the device driver may stop receiving data on a UP system? It will
never get the ack.
Not sure to follow, sorry.
My idea was:
post the invalidate in the mmio region of the device
smp_call_function()
while
On Thu, Feb 28, 2008 at 05:03:01PM -0800, Christoph Lameter wrote:
I thought you wanted to get rid of the sync via pte lock?
Sure. _notify is happening inside the pt lock by coincidence, to
reduce the changes to mm/* as long as the mmu notifiers aren't
sleep capable.
What changes to do_wp_page
On 2/29/08, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Fri, 2008-02-29 at 16:55 +0800, Zhao Forrest wrote:
Sorry for reposting it.
For example,
1 rdtsc() is invoked on CPU0
2 process is migrated to CPU1, and rdtsc() is invoked on CPU1
3 if TSC on CPU1 is slower than TSC on CPU0, can
On Mon, 18 Feb 2008 10:39:31 +0100
Alexander Graf [EMAIL PROTECTED] wrote:
So if you want to see a VMentry failure, just remove the SS patching
and you'll see one. My guess would be that you see a lot of problems
with otherwise working code too then, though, as SS can be anything in
that
On Fri, 2008-02-29 at 22:20 +0800, Zhao Forrest wrote:
On 2/29/08, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Fri, 2008-02-29 at 16:55 +0800, Zhao Forrest wrote:
Sorry for reposting it.
For example,
1 rdtsc() is invoked on CPU0
2 process is migrated to CPU1, and rdtsc() is
On Fri, Feb 29, 2008 at 2:33 AM, Arnon Gilboa [EMAIL PROTECTED] wrote:
In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);
With usb_ehci_init(pci_bus, piix3_devfn + 2);
With these changes.. I can't add the usb devices anymore to a Windows
XP (32 bit).
This is the command i use
Online Apotheke - original Qualitaet - 100% wirksam
Spezialangebot: Vi. 10 Tab. 100 mg + Ci. 10 Tab. x 20 mg 53,82 Euro
Vi. 10 Tab. 26,20 Euro
Vi. 30 Tab. 51,97 Euro - Sie sparen: 27,00 Euro
Vi. 60 Tab. 95,69 Euro - Sie sparen: 62,00 Euro
Vi. 90 Tab. 136,91 Euro - Sie sparen: 100,00 Euro
Ci.
Whereas KVM-60 builds out of the box on SLES 10 SP1 (assuming gcc 3.4 is
installed), KVM-61 and KVM-62 don't. They fail with:
make[1]: Entering directory `/scratch/KVM/kvm-61/kernel'
# include header priority 1) INUX 2) ERNELDIR 3) include-compat
make -C /lib/modules/2.6.16.54-0.2.5-smp/build
On Fri, 29 Feb 2008, M.J. Rutter wrote:
Whereas KVM-60 builds out of the box on SLES 10 SP1 (assuming gcc 3.4 is
installed), KVM-61 and KVM-62 don't.
Bother. Ignore that. As far as I can see, no KVM since about KVM-37 has
actually run on a kernel that old, due to the lack of hrtimer_init and
Hello All,
Is there a significant performance advantage with using a 64bit host os? I
am specifically wondering about the advantages where KVM and QEMU are
concerned.
Thanks in advance,
-G
-
This SF.net email is
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
On Thu, Feb 28, 2008 at 05:03:01PM -0800, Christoph Lameter wrote:
I thought you wanted to get rid of the sync via pte lock?
Sure. _notify is happening inside the pt lock by coincidence, to
reduce the changes to mm/* as long as the mmu notifiers
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
On Thu, Feb 28, 2008 at 04:59:59PM -0800, Christoph Lameter wrote:
And thus the device driver may stop receiving data on a UP system? It will
never get the ack.
Not sure to follow, sorry.
My idea was:
post the invalidate in the mmio
On Fri, Feb 29, 2008 at 11:55:17AM -0800, Christoph Lameter wrote:
post the invalidate in the mmio region of the device
smp_call_function()
while (mmio device wait-bitflag is on);
So the device driver on UP can only operate through interrupts? If you are
hogging the only cpu
ציטוט [EMAIL PROTECTED]:
Hello All,
Is there a significant performance advantage with using a 64bit host
os? I am specifically wondering about the advantages where KVM and
QEMU are concerned.
the mmu code (the page table entries pointers are 64bits) would run
faster on 64bits host
i
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
Agreed. I just thought xpmem needed an invalidate-by-page, but
I'm glad if xpmem can go in sync with the KVM/GRU/DRI model in this
regard.
That means we need both the anon_vma locks and the i_mmap_lock to become
semaphores. I think semaphores are
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
On Fri, Feb 29, 2008 at 01:03:16PM -0800, Christoph Lameter wrote:
That means we need both the anon_vma locks and the i_mmap_lock to become
semaphores. I think semaphores are better than mutexes. Rik and Lee saw
some performance improvements
On Fri, Feb 29, 2008 at 01:34:34PM -0800, Christoph Lameter wrote:
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
On Fri, Feb 29, 2008 at 01:03:16PM -0800, Christoph Lameter wrote:
That means we need both the anon_vma locks and the i_mmap_lock to become
semaphores. I think semaphores are
On Fri, Feb 29, 2008 at 01:03:16PM -0800, Christoph Lameter wrote:
That means we need both the anon_vma locks and the i_mmap_lock to become
semaphores. I think semaphores are better than mutexes. Rik and Lee saw
some performance improvements because list can be traversed in parallel
when
On Fri, Feb 29, 2008 at 02:12:57PM -0800, Christoph Lameter wrote:
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
AFAICT The rw semaphore fastpath is similar in performance to a rw
spinlock.
read side is taken in the slow path.
Slowpath meaning VM slowpath or lock slow path? Its
25 matches
Mail list logo
