* Re: [RFC PATCH 01/35] Add XEN config options and disable unsupported config options.
From: Chris Wright @ 2006-05-09 23:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: xen-devel, Ian Pratt, linux-kernel, Chris Wright, virtualization,
Christian Limpach
In-Reply-To: <20060509100547.GL3570@stusta.de>
* Adrian Bunk (bunk@stusta.de) wrote:
> On Tue, May 09, 2006 at 12:00:01AM -0700, Chris Wright wrote:
> >...
> > --- linus-2.6.orig/arch/i386/Kconfig
> > +++ linus-2.6/arch/i386/Kconfig
> >...
> > config X86_IO_APIC
> > bool
> > - depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER))
> > + depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER || X86_XEN))
> > default y
> >...
>
> <nitpick>not required</nitpick>
True, although SMP is just disabled in this patchset which is a subset
of full Xen support.
thanks,
-chris
^ permalink raw reply
* Re: [RFC PATCH 01/35] Add XEN config options and disable unsupported config options.
From: Chris Wright @ 2006-05-09 23:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: Chris Wright, linux-kernel, virtualization, xen-devel, Ian Pratt,
Christian Limpach
In-Reply-To: <20060509100547.GL3570@stusta.de>
* Adrian Bunk (bunk@stusta.de) wrote:
> On Tue, May 09, 2006 at 12:00:01AM -0700, Chris Wright wrote:
> >...
> > --- linus-2.6.orig/arch/i386/Kconfig
> > +++ linus-2.6/arch/i386/Kconfig
> >...
> > config X86_IO_APIC
> > bool
> > - depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER))
> > + depends on X86_UP_IOAPIC || (SMP && !(X86_VISWS || X86_VOYAGER || X86_XEN))
> > default y
> >...
>
> <nitpick>not required</nitpick>
True, although SMP is just disabled in this patchset which is a subset
of full Xen support.
thanks,
-chris
^ permalink raw reply
* Re: [RFC PATCH 01/35] Add XEN config options and disable unsupported config options.
From: Chris Wright @ 2006-05-09 23:25 UTC (permalink / raw)
To: Daniel Walker
Cc: Christian Limpach, Chris Wright, linux-kernel, virtualization,
xen-devel, Ian Pratt
In-Reply-To: <1147190433.21536.28.camel@c-67-180-134-207.hsd1.ca.comcast.net>
* Daniel Walker (dwalker@mvista.com) wrote:
> I guess that true .. Might be better just to support SMP then ..
Yes, and of course Xen does. This is just the smallest functional set of
patches to get discussion, so the SMP bits were dropped for now.
thanks,
-chris
^ permalink raw reply
* Re: [Qemu-devel] QEMU 0.8.1
From: Thomas Han @ 2006-05-09 23:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <445AB8FE.9040003@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]
Hi Anthony,
Sorry for the late reply. I did try out the patch with my local build and I
haven't see that "invisible wall" mouse problem for a few days now.
Thanks very much,
Thomas
On 5/4/06, Anthony Liguori <aliguori@us.ibm.com> wrote:
>
> Thomas Han wrote:
> > Hi,
> >
> > For what it's worth. I have also seen this "invisible wall" problem
> > with my mouse for a few weeks off the CVS build too.
>
> Can you try out the following patch. *grumbles about SDL's brokenness*
>
> Regards,
>
> Anthony Liguori
>
> > Since 0.8.1 came out yesterday, Instead of using CVS build, I'm now
> > running Qemu 0.8.1 + kqemu-1.3.0pre6. My host OS is FC5 and I'm
> > running XP inside it.
> >
> > Thanks,
> > Thomas
> >
> > On 5/4/06, *Christian MICHON* < christian.michon@gmail.com
> > <mailto:christian.michon@gmail.com>> wrote:
> >
> > qemu 0.8.0 does not show this invisible barrier issue.
> > if this is worth anything, I use SDL 1.2.9.
> >
> > If someone can reproduce the issue also on linux hosts,
> > there could be a lead.
> >
> > On 5/4/06, Christian MICHON <christian.michon@gmail.com
> > <mailto:christian.michon@gmail.com>> wrote:
> > > I removed manually vnc_display_init, and this is not the
> culprit...
> > > I'll check anyway versus qemu-0.8.0...
> > >
> > --
> > Christian
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org <mailto:Qemu-devel@nongnu.org>
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
>
>
>
> diff -r 39a6dd1136c6 sdl.c
> --- a/sdl.c Thu May 04 04:13:13 2006 +0000
> +++ b/sdl.c Thu May 04 21:30:11 2006 -0500
> @@ -280,13 +280,18 @@ static void sdl_update_caption(void)
>
> static void sdl_hide_cursor(void)
> {
> - SDL_SetCursor(sdl_cursor_hidden);
> + if (kbd_mouse_is_absolute()) {
> + SDL_ShowCursor(1);
> + SDL_SetCursor(sdl_cursor_hidden);
> + } else {
> + SDL_ShowCursor(0);
> + }
> }
>
> static void sdl_show_cursor(void)
> {
> if (!kbd_mouse_is_absolute()) {
> - SDL_SetCursor(sdl_cursor_normal);
> + SDL_ShowCursor(1);
> }
> }
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
[-- Attachment #2: Type: text/html, Size: 4400 bytes --]
^ permalink raw reply
* RE: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
From: Meswani, Mitesh @ 2006-05-09 23:17 UTC (permalink / raw)
To: Segher Boessenkool, will_schmidt; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18583972-9E29-4B52-BF2E-53102F1794EB@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]
Thanks guys
That answered so many of my questions.
If I were to use these macros from user space, would they remain set until next reboot or change ? POWER5 allows priorities 2 through 4 for user apps, so considering this, and the fact that the normal prioirity is level 4, if a user app resets it to say 2 and then finishes without changing it back to 4 , would all the subsequent user apps run at the new level 2. I wonder what I am saying even makes sense, because the kernel internally throttles the priority for various sections of the kernel code and it may even overwrite it.
On a slightly unrelated note, I appended some boot parameters like smt-enabled=on/off to /etc/lilo.conf and unfortunately I am not able to see any effect and it boots the same way. I am switching from the AIX world so I maybe doing something dumb, please point out if I am ! This kind of seems to effect the bind processor calls using sys_setaffinity when there are 4 logical processors 0-3 on two physical processors, bind only allows me to set affinity to either cpu 0 or 2, this seems weird to me because my system is booting with two logical cpus and then I set online bit to 1 to turn the remaining on, thereafter I try binding and havent been very successful.
Thanks for all your replies.
Mitesh R. Meswani
Ph.D. Candidate
Research Associate, PLS2 Group
Room 106 F, Department of Computer Science
The University of Texas at El Paso,
El Paso, Texas 79968
Tel: 915 747 8012 (O)
Email: mmeswani@utep.edu
________________________________
From: Segher Boessenkool [mailto:segher@kernel.crashing.org]
Sent: Mon 5/8/2006 5:04 PM
To: will_schmidt@vnet.ibm.com
Cc: Meswani, Mitesh; linuxppc-dev@ozlabs.org; Arnd Bergmann; linux-kernel@vger.kernel.org; cbe-oss-dev@ozlabs.org
Subject: Re: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
> the HMT_* macros are telling firmware that "this processor thread
> should
> run at this priority". Typically used when we're waiting on a
> spinlock.
> I.e. When we are waiting on a spinlock, we hit the HMT_low macro to
> drop
> our threads priority, allowing the other thread to use those extra
> cycles finish it's stuff quicker, and maybe even release the lock
> we're
> waiting for. HMT_* is all within the kernel though, no
> exposure
> to userspace apps.
Actually, those macros translate straight into a single machine insn.
No firmware is involved. See include/asm-powerpc/processor.h. For
example:
#define HMT_very_low() asm volatile("or 31,31,31 # very low
priority")
You can use those same macros from user space, although it is CPU
implementation dependent which priorities you can actually set (you
probably can do low and medium priority).
Segher
[-- Attachment #2: Type: text/html, Size: 4525 bytes --]
^ permalink raw reply
* O dia Mundial da Criança
From: Está a chegar @ 2006-05-09 23:15 UTC (permalink / raw)
To: nfs
[-- Attachment #1.1: Type: text/plain, Size: 464 bytes --]
All-Days
Tshirts & Gifts DIA 1 de Junho é o dia MUNDIAL
da CRIANÇA
Tees para todas as ocasiões.
Vários modelos e cores.
Totalmente personalizáveis.
Promoção Primavera
- Três tees por 19,00
- Três sweats oferta portes
- Pólo Grande qualidade oferta de um boné
Ofereça-lhes com amor
uma t-shirt diferente
Retirem o meu email da vossa lista
[-- Attachment #1.2: Type: text/html, Size: 3195 bytes --]
[-- Attachment #2: dia1.jpg --]
[-- Type: image/jpeg, Size: 11289 bytes --]
^ permalink raw reply
* Re: Some questions about using heavy iptables rules in a Linux box ....
From: John A. Sullivan III @ 2006-05-09 23:14 UTC (permalink / raw)
To: hbchen; +Cc: netfilter-devel
In-Reply-To: <4460B502.4080903@lanl.gov>
On Tue, 2006-05-09 at 09:28 -0600, hbchen wrote:
> Hi,
> I have some questions about using heavy iptables rules in a Linux box.
> 1. Has anyone done a comparison of latency and throughput on traffic
> through an
> Linux node with and without IPtables (using lots of filtering rules)?
> 2. How much CPU time is spending on iptables (heavy filtering rules)?
> 3. Any significant impact (latency and throughput) on 10G ethernet link?
<snip>
I cannot help you much with measurements but I can relate some
production experiences we have had using the ISCS network security
management project with iptables to implement intra-perimeter security.
In these cases, we needed to deal with massive rule sets (>150,000
rules). As a result, we are successfully running this installation on
low end, off-the-shelf iptables appliances from CyberGuard (SG series).
Obviously, these are not handling 10Gbps traffic streams!
The ISCS (http://iscs.sourceforge.net) paradigm uses standard iptables
in a slightly different way to reduce the overhead associated with very
large rule sets such as those needed for interior security. We still
answer the question who has access to what but evaluate who separately
from what. The result is a modular rather than monolithic rule set.
Instead of needing a separate rule for every possible combination of who
and what, we need a single rule for each who and a single rule for each
what and then mix and match them.
In this particular installation, the 150,000 monolithic rules were
reduced to about 13,000 modular rules. I suppose we could do much
better if we implemented ipset. Not only that, but the traversal of the
rules is effectively indexed by "who" thus dramatically improving
performance. And the entire rule set took only a few hours to
automatically create and distribute using ISCS.
Hopefully, you can use a similar approach to reduce the load and
increase processing efficiency in your environment - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com
Financially sustainable open source development
http://www.opensourcedevel.com
^ permalink raw reply
* Re: [RFC PATCH 25/35] Add Xen time abstractions
From: Chris Wright @ 2006-05-09 23:13 UTC (permalink / raw)
To: Ingo Oeser
Cc: xen-devel, Ian Pratt, Andi Kleen, linux-kernel, Chris Wright,
virtualization
In-Reply-To: <200605100103.54875.ioe-lkml@rameria.de>
* Ingo Oeser (ioe-lkml@rameria.de) wrote:
> On Tuesday, 9. May 2006 23:50, Andi Kleen wrote:
> > On Tuesday 09 May 2006 09:00, Chris Wright wrote:
> > > Add support for Xen time abstractions. To avoid expensive traps into
> > > the hypervisor, the passage of time is extrapolated from the local TSC
> > > and a set of timestamps and scaling factors exported to the guest via
> > > shared memory. Xen also provides a periodic interrupt facility which
> > > is used to drive updates of xtime and jiffies, and perform the usual
> > > process accounting and profiling.
> >
> > There is far too much code duplication in there. I think you need to
> > refactor the main time.c a bit first and strip that down.
> >
> > Also you can drop all the __x86_64__ support for now.
>
> Isn't time and timer handling a moving target anyway?
> The refactoring will be done by the timer people in a completly different
> manner anyway.
>
> Are you sure, you want to disturb these efforts by requiring another
> refactoring here?
Yes. Otherwise we end up with either duplicated code if the moving
target winds up not moving, or outdated code if it does. I agree with
Andi. It's on the todo list to refactor, but I wanted to get the
patches out even though it's a work in progress.
thanks,
-chris
^ permalink raw reply
* RE: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows
From: Dugger, Donald D @ 2006-05-09 23:12 UTC (permalink / raw)
To: qemu-devel
Leo-
Yeah, I started there but it turns out there are multiple reasons why
that is the wrong place to fix things:
1) `hw/vga.c' only knows about resolution changes, the bug also appears
if you change the pixel size, e.g. 24 bpp to 16 bpp.
2) Technically, because of the lazy screen update, your change would be
too late. To improve performance the vga code is only called
periodically, not after every VRAM change. It is theoretically possible
for the target to change video mode, assume VRAM got reset, do a bitblt
from non-visible VRAM to visible VRAM and then have the `hw/vga.c' code
get called, overwriting the changes done to visible VRAM.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@intel.com
Ph: (303)440-1368
>-----Original Message-----
>From: qemu-devel-bounces+donald.d.dugger=intel.com@nongnu.org
>[mailto:qemu-devel-bounces+donald.d.dugger=intel.com@nongnu.org
>] On Behalf Of Leonardo E. Reiter
>Sent: Tuesday, May 09, 2006 2:29 PM
>To: qemu-devel@nongnu.org
>Subject: Re: [Qemu-devel] [PATCH]Fix for minor video
>corruption under Windows
>
>Donald...
>
>thanks... I actually posted a patch to fix this sometime ago, but your
>patch seems more thorough and probably more correct. Just FYI, I
>attached my patch again. I will test your patch as well.
>
>Thanks again,
>
>Leo Reiter
>
>Donald D. Dugger wrote:
>> If you change the video resolution while running a Windows
>XP image such that
>> it uses fewer bytes of VRAM (either by using fewer bytes per
>pixel or by
>> lowering the resolution) then some window backgrounds will
>become corrupted.
>> This happens because the Windows XP Cirrus Logic driver
>assumes that VRAM is
>> initialized to 0xff whenever the video mode switches between
>VGA and SVGA.
>>
>> This patch fixes this problem by resetting VRAM whenever a
>VGA/SVGA mode switch
>> occurs.
>>
>> Signed-off-by: Donald.D.Dugger@intel.com
>>
>
>--
>Leonardo E. Reiter
>Vice President of Product Development, CTO
>
>Win4Lin, Inc.
>Virtual Computing that means Business
>Main: +1 512 339 7979
>Fax: +1 512 532 6501
>http://www.win4lin.com
>
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, Johannes.Schindelin, git
In-Reply-To: <20060509184519.5a707231.seanlkml@sympatico.ca>
On Tue, 9 May 2006 18:45:19 -0400
sean <seanlkml@sympatico.ca> wrote:
> > How does a program (not a script, but git_config() users) get
> > that value and parse it?
>
> The same way they do now. For instance git-repo-config processes
> the config file using the same get_config() + callback as usual. The
> only issue is that they should no longer cast everything to lower first.
Junio,
Sorry I see what you're driving at; how does a program break the section
name into it's constituent pieces. I glossed over this issue because
it's exactly the same between Linus' proposal and mine. The answer is,
they really can't, with either proposal.
All you can count on (by convention) is that there is an initial segment
that is terminated by a period; and a final segment that starts with a
period, and everything in between is an opaque unit.
section.<random string>.keyname value
Although the initial "section." isn't currently enforced (but easily
could be). Actually i didn't yank out the bit from config.c that
validates the keyname, so without an additional patch the only way
to enter the extended names is by manual editing of the .git/config.
Sean
^ permalink raw reply
* RE: Viable PPC platform?
From: Howard, Marc @ 2006-05-09 23:11 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> > > In message <20060509171520.GA10886@gate.ebshome.net> you wrote:
> > > >
> > > > After many years of doing embedded Linux stuff I still don't=20
> > > > understand why people are so fond of initrd.
> > > >=20
> > One size does not fit all. We have an application with a very large
> > file system. It can't fit in the available flash, however=20
> we do have a
> > ton of RAM (512MB). NFS is not an option nor is it=20
> desirable (latency
> > and availability issues). Boot time is not an issue either=20
> in this case
> > as it takes the equipment many minutes to calibrate and initialize.
> >=20
> > initrd also solves another problem. The combined uBoot multi-image
> > although huge (>32 MB) represents a complete system=20
> firmware snapshot in
> > a single (huge) file. By selecting the appropriate uImage=20
> the host can
> > guarantee the linux build, device drivers, application=20
> version and FPGA
> > firmware revs (the embedded board is rebooted to guarantee=20
> a repeatable
> > starting state). This makes revision control for the overall system
> > much easier, especially since the host system is running windoze.
>=20
> This all is nice provided you use network for boot. IMHO this=20
> is quite=20
> _rare_ setup (especially Windows host!!!). For 99% of=20
> embedded designs=20
> this is obviously not a viable option.
>=20
> --=20
> Eugene
Again, I agree. I just wanted to show you at least one case where
initrd is the best solution, IMHO.
As for a linux board booting off of a windoze host I prefer to think of
it as an island of sanity in a sea of chaos.
Marc W. Howard
^ permalink raw reply
* Re: [RFC PATCH 25/35] Add Xen time abstractions
From: Chris Wright @ 2006-05-09 23:13 UTC (permalink / raw)
To: Ingo Oeser
Cc: Andi Kleen, virtualization, Chris Wright, linux-kernel, xen-devel,
Ian Pratt
In-Reply-To: <200605100103.54875.ioe-lkml@rameria.de>
* Ingo Oeser (ioe-lkml@rameria.de) wrote:
> On Tuesday, 9. May 2006 23:50, Andi Kleen wrote:
> > On Tuesday 09 May 2006 09:00, Chris Wright wrote:
> > > Add support for Xen time abstractions. To avoid expensive traps into
> > > the hypervisor, the passage of time is extrapolated from the local TSC
> > > and a set of timestamps and scaling factors exported to the guest via
> > > shared memory. Xen also provides a periodic interrupt facility which
> > > is used to drive updates of xtime and jiffies, and perform the usual
> > > process accounting and profiling.
> >
> > There is far too much code duplication in there. I think you need to
> > refactor the main time.c a bit first and strip that down.
> >
> > Also you can drop all the __x86_64__ support for now.
>
> Isn't time and timer handling a moving target anyway?
> The refactoring will be done by the timer people in a completly different
> manner anyway.
>
> Are you sure, you want to disturb these efforts by requiring another
> refactoring here?
Yes. Otherwise we end up with either duplicated code if the moving
target winds up not moving, or outdated code if it does. I agree with
Andi. It's on the todo list to refactor, but I wanted to get the
patches out even though it's a work in progress.
thanks,
-chris
^ permalink raw reply
* Re: [RFC PATCH 25/35] Add Xen time abstractions
From: Andi Kleen @ 2006-05-09 23:09 UTC (permalink / raw)
To: Ingo Oeser
Cc: virtualization, Chris Wright, linux-kernel, xen-devel, Ian Pratt
In-Reply-To: <200605100103.54875.ioe-lkml@rameria.de>
> Isn't time and timer handling a moving target anyway?
> The refactoring will be done by the timer people in a completly different
> manner anyway.
>
> Are you sure, you want to disturb these efforts by requiring another
> refactoring here?
Yes I am.
-Andi
^ permalink raw reply
* Re: [RFC PATCH 25/35] Add Xen time abstractions
From: Andi Kleen @ 2006-05-09 23:09 UTC (permalink / raw)
To: Ingo Oeser
Cc: Chris Wright, virtualization, xen-devel, linux-kernel, Ian Pratt
In-Reply-To: <200605100103.54875.ioe-lkml@rameria.de>
> Isn't time and timer handling a moving target anyway?
> The refactoring will be done by the timer people in a completly different
> manner anyway.
>
> Are you sure, you want to disturb these efforts by requiring another
> refactoring here?
Yes I am.
-Andi
^ permalink raw reply
* Re: [RFC PATCH 05/35] Add sync bitops
From: Chris Wright @ 2006-05-09 23:07 UTC (permalink / raw)
To: Christoph Lameter
Cc: xen-devel, Ian Pratt, linux-kernel, Chris Wright, virtualization,
Christian Limpach
In-Reply-To: <Pine.LNX.4.64.0605091555540.30338@schroedinger.engr.sgi.com>
* Christoph Lameter (clameter@sgi.com) wrote:
> On Tue, 9 May 2006, Chris Wright wrote:
>
> > Add "always lock'd" implementations of set_bit, clear_bit and
> > change_bit and the corresponding test_and_ functions. Also add
> > "always lock'd" implementation of cmpxchg. These give guaranteed
> > strong synchronisation and are required for non-SMP kernels running on
> > an SMP hypervisor.
>
> Could you explain why this is done and what is exactly meant with "always
> looked"? Wh the performance impact?
The standard UP bitops are not atomic. But a UP guest may be on SMP
machine, and the bitmaps here are shared between guests. The always
locked means the lock prefix is not conditional on either UP build
(or smp alternatives patching), and memory barriers are in place.
There's no performance penalty unless you use them, as it's a new set
(somewhat similar to the bitops changes you were looking into). Although,
this is the simplest, with no multiplexing, simply new interface, synch_*.
Open to ideas here. Xen is another possible consumer of your bitops
changes.
thanks,
-chris
^ permalink raw reply
* Re: [RFC PATCH 25/35] Add Xen time abstractions
From: Ingo Oeser @ 2006-05-09 23:03 UTC (permalink / raw)
To: Andi Kleen
Cc: virtualization, Chris Wright, linux-kernel, xen-devel, Ian Pratt
In-Reply-To: <200605092350.03886.ak@suse.de>
Hi Andi,
On Tuesday, 9. May 2006 23:50, Andi Kleen wrote:
> On Tuesday 09 May 2006 09:00, Chris Wright wrote:
> > Add support for Xen time abstractions. To avoid expensive traps into
> > the hypervisor, the passage of time is extrapolated from the local TSC
> > and a set of timestamps and scaling factors exported to the guest via
> > shared memory. Xen also provides a periodic interrupt facility which
> > is used to drive updates of xtime and jiffies, and perform the usual
> > process accounting and profiling.
>
> There is far too much code duplication in there. I think you need to
> refactor the main time.c a bit first and strip that down.
>
> Also you can drop all the __x86_64__ support for now.
Isn't time and timer handling a moving target anyway?
The refactoring will be done by the timer people in a completly different
manner anyway.
Are you sure, you want to disturb these efforts by requiring another
refactoring here?
Regards
Ingo Oeser
^ permalink raw reply
* RE: [PATCH][SPT][DISCUSS] BUG() in shadow.h delete_shadow_status() with HVM guest
From: Woller, Thomas @ 2006-05-09 23:06 UTC (permalink / raw)
To: Nakajima, Jun, xen-devel
> I think this is a bit different because the hash key has the
> index of the PDP for PAE guests. I guess somehow
> tlbflush_timestamp has been modified. Can you try this patch?
Thanks for the reply and the fix - your patch was successful on both SVM
and VMX boxes. I tested 32bit PAE win2003 server SE on SVM, and 32bit
PAE Winxpsp2 on VMX. Both did not hit the BUG() in shadow.h.
We definitely don't have much priority with PAE here, might be prudent
to let this patch sit with your more extensive PAE testing, including
32bit hv, etc. We'll use your patch internally for a while, and
indicate if we see an adverse side-affects.
So, unless you indicate otherwise, I'll defer to you to push up when you
feel it's a solid fix.
thanks
Tom
> diff -r 1e3977e029fd xen/arch/x86/shadow.c
> --- a/xen/arch/x86/shadow.c Mon May 8 18:21:41 2006
> +++ b/xen/arch/x86/shadow.c Tue May 9 13:20:33 2006
> @@ -3467,7 +3467,9 @@
> } else {
> printk("For non HVM shadow,
> create_l1_shadow:%d\n", create_l2_shadow);
> }
> - shadow_update_min_max(l4e_get_pfn(sl4e),
> l3_table_offset(va));
> +
> + if ( v->domain->arch.ops->guest_paging_levels == PAGING_L4 )
> + shadow_update_min_max(l4e_get_pfn(sl4e),
> l3_table_offset(va));
>
^ permalink raw reply
* Re: [RFC PATCH 05/35] Add sync bitops
From: Andi Kleen @ 2006-05-09 23:04 UTC (permalink / raw)
To: virtualization
Cc: Christoph Lameter, Chris Wright, xen-devel, linux-kernel,
Ian Pratt
In-Reply-To: <Pine.LNX.4.64.0605091555540.30338@schroedinger.engr.sgi.com>
On Wednesday 10 May 2006 00:56, Christoph Lameter wrote:
> On Tue, 9 May 2006, Chris Wright wrote:
>
> > Add "always lock'd" implementations of set_bit, clear_bit and
> > change_bit and the corresponding test_and_ functions. Also add
> > "always lock'd" implementation of cmpxchg. These give guaranteed
> > strong synchronisation and are required for non-SMP kernels running on
> > an SMP hypervisor.
>
> Could you explain why this is done and what is exactly meant with "always
> looked"? Wh the performance impact?
When UP guest runs on SMP hypervisor they still need the LOCK prefix
to talk to the hypervisor through shared memory in a smp safe way.
Normally UP kernels don't use any LOCK prefixes.
I suggested to refactor the bitops this way earlier for this.
-Andi
^ permalink raw reply
* Re: [RFC PATCH 05/35] Add sync bitops
From: Andi Kleen @ 2006-05-09 23:04 UTC (permalink / raw)
To: virtualization
Cc: Chris Wright, Ian Pratt, xen-devel, linux-kernel,
Christoph Lameter
In-Reply-To: <Pine.LNX.4.64.0605091555540.30338@schroedinger.engr.sgi.com>
On Wednesday 10 May 2006 00:56, Christoph Lameter wrote:
> On Tue, 9 May 2006, Chris Wright wrote:
>
> > Add "always lock'd" implementations of set_bit, clear_bit and
> > change_bit and the corresponding test_and_ functions. Also add
> > "always lock'd" implementation of cmpxchg. These give guaranteed
> > strong synchronisation and are required for non-SMP kernels running on
> > an SMP hypervisor.
>
> Could you explain why this is done and what is exactly meant with "always
> looked"? Wh the performance impact?
When UP guest runs on SMP hypervisor they still need the LOCK prefix
to talk to the hypervisor through shared memory in a smp safe way.
Normally UP kernels don't use any LOCK prefixes.
I suggested to refactor the bitops this way earlier for this.
-Andi
^ permalink raw reply
* Re: [RFC PATCH 05/35] Add sync bitops
From: Chris Wright @ 2006-05-09 23:07 UTC (permalink / raw)
To: Christoph Lameter
Cc: Chris Wright, linux-kernel, virtualization, xen-devel, Ian Pratt,
Christian Limpach
In-Reply-To: <Pine.LNX.4.64.0605091555540.30338@schroedinger.engr.sgi.com>
* Christoph Lameter (clameter@sgi.com) wrote:
> On Tue, 9 May 2006, Chris Wright wrote:
>
> > Add "always lock'd" implementations of set_bit, clear_bit and
> > change_bit and the corresponding test_and_ functions. Also add
> > "always lock'd" implementation of cmpxchg. These give guaranteed
> > strong synchronisation and are required for non-SMP kernels running on
> > an SMP hypervisor.
>
> Could you explain why this is done and what is exactly meant with "always
> looked"? Wh the performance impact?
The standard UP bitops are not atomic. But a UP guest may be on SMP
machine, and the bitmaps here are shared between guests. The always
locked means the lock prefix is not conditional on either UP build
(or smp alternatives patching), and memory barriers are in place.
There's no performance penalty unless you use them, as it's a new set
(somewhat similar to the bitops changes you were looking into). Although,
this is the simplest, with no multiplexing, simply new interface, synch_*.
Open to ideas here. Xen is another possible consumer of your bitops
changes.
thanks,
-chris
^ permalink raw reply
* [uml-devel] really
From: Ignacio @ 2006-05-09 23:03 UTC (permalink / raw)
To: Winted; +Cc: regina-user, effectv-developers, jregex-user, pdftohtml-general
If your still looking to save 59 per cnet on ur goods, then come here
www.firstroachonmyheight.org/xvr/. street the was there
and sure that are came an the piece,
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [RFC] dm-userspace
From: Dan Smith @ 2006-05-09 23:02 UTC (permalink / raw)
To: mingz; +Cc: device-mapper development, Xen Developers, linux-kernel
In-Reply-To: <1146092129.14129.333.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 2828 bytes --]
(I'm including the xen-devel list on this, as things are starting to
get interesting).
MZ> do u have any benchmark results about overhead?
So, I've spent some time over the last week working to improve
performance and collect some benchmark data.
I moved to using slab caches for the request and remap objects, which
helped a little. I also added a poll() method to the control device,
which improved performance significantly. Finally, I changed the
internal remap storage data structure to a hash table, which had a
very large performance impact (about 8x).
Copying data to a device backed by dm-userspace presents a worst-case
scenario, especially with a small block-size like what qcow uses. In
one of my tests, I copy about 20MB of data to a dm-userspace device,
backed by files hooked up to the loopback driver. I compare this with
a "control" of a single loop-mounted image file (i.e., without
dm-userspace or CoW). I measured the time to mount, copy, and unmount
the device, which (with the recent performance improvements) are
approximately:
Normal Loop: 1 seconds
dm-userspace/qcow: 10 seconds
For comparison, before adding poll() and the hash table, the
dm-userspace number was over 70 seconds.
One of the most interesting cases for us, however, is providing a
CoW-based VM disk image, which is mostly used for reading, with a
small amount of writing for configuration data. To test this, I used
Xen to compare a fresh FC4 boot (firstboot, where things like SSH keys
are generated and written to disk) that used an LVM volume as root to
using dm-userspace (and loopback-files) as the root. The numbers are
approximately:
LVM root: 26 seconds
dm-userspace/qcow: 27 seconds
Note that this does not yet include any read-ahead type behavior, nor
does it include priming the kernel module with remaps at create-time
(which results in a few initial compulsory "misses"). Also, I removed
the remap expiration functionality while adding the hash table and
have not yet added it back, so that may further improve performance
for large amounts of remaps (and bucket collisions).
Here is a link to a patch against 2.6.16.14:
http://static.danplanet.com/dm-userspace/dmu-2.6.16.14-patch
Here are links to the userspace library, as well as the cow daemon,
which provides qcow support:
http://static.danplanet.com/dm-userspace/libdmu-0.2.tar.gz
http://static.danplanet.com/dm-userspace/cowd-0.1.tar.gz
(Note that the daemon is still rather rough, and the qcow
implementation has some bugs. However, it works for light testing and
the occasional luck-assisted heavy testing)
As always, comments welcome and appreciated :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 190 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: [IA64] rework memory attribute aliasing
From: Luck, Tony @ 2006-05-09 23:02 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <200605051719.50884.bjorn.helgaas@hp.com>
> This closes a couple holes in our attribute aliasing avoidance scheme:
Looks good ... and adds some Documentation too: double bonus points :-)
Fixes the X issue on Intel Tiger platform, and your MCA with
Obsidian II problem: earns free replay :-)
If we were at -rc2, I'd just slide this right into Linus ... but we are
a bit close to 2.6.17, so I'm polling for regression testing. I don't
want to find out that this breaks some other platform.
-Tony
^ permalink raw reply
* ParaGuest cannot see 30GB memory
From: pak333 @ 2006-05-09 23:01 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 361 bytes --]
Hi,
I have buit Xen (32 bit) with PAE and can start multiple Paraguests with 4 gig memory, but cannot launch a single VM with more than 4 gb memory. I would like to launch 1 VM with 30GB or so memory. Are there any config paramters like kernel,/inittrd that need to be changed.
I have the ramdisk set to the initrd I used to boot xen with PAE.
Thanks
- padma
[-- Attachment #1.2: Type: text/html, Size: 514 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [dm-devel] [RFC] dm-userspace
From: Dan Smith @ 2006-05-09 23:02 UTC (permalink / raw)
To: mingz; +Cc: device-mapper development, linux-kernel, Xen Developers
In-Reply-To: <1146092129.14129.333.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]
(I'm including the xen-devel list on this, as things are starting to
get interesting).
MZ> do u have any benchmark results about overhead?
So, I've spent some time over the last week working to improve
performance and collect some benchmark data.
I moved to using slab caches for the request and remap objects, which
helped a little. I also added a poll() method to the control device,
which improved performance significantly. Finally, I changed the
internal remap storage data structure to a hash table, which had a
very large performance impact (about 8x).
Copying data to a device backed by dm-userspace presents a worst-case
scenario, especially with a small block-size like what qcow uses. In
one of my tests, I copy about 20MB of data to a dm-userspace device,
backed by files hooked up to the loopback driver. I compare this with
a "control" of a single loop-mounted image file (i.e., without
dm-userspace or CoW). I measured the time to mount, copy, and unmount
the device, which (with the recent performance improvements) are
approximately:
Normal Loop: 1 seconds
dm-userspace/qcow: 10 seconds
For comparison, before adding poll() and the hash table, the
dm-userspace number was over 70 seconds.
One of the most interesting cases for us, however, is providing a
CoW-based VM disk image, which is mostly used for reading, with a
small amount of writing for configuration data. To test this, I used
Xen to compare a fresh FC4 boot (firstboot, where things like SSH keys
are generated and written to disk) that used an LVM volume as root to
using dm-userspace (and loopback-files) as the root. The numbers are
approximately:
LVM root: 26 seconds
dm-userspace/qcow: 27 seconds
Note that this does not yet include any read-ahead type behavior, nor
does it include priming the kernel module with remaps at create-time
(which results in a few initial compulsory "misses"). Also, I removed
the remap expiration functionality while adding the hash table and
have not yet added it back, so that may further improve performance
for large amounts of remaps (and bucket collisions).
Here is a link to a patch against 2.6.16.14:
http://static.danplanet.com/dm-userspace/dmu-2.6.16.14-patch
Here are links to the userspace library, as well as the cow daemon,
which provides qcow support:
http://static.danplanet.com/dm-userspace/libdmu-0.2.tar.gz
http://static.danplanet.com/dm-userspace/cowd-0.1.tar.gz
(Note that the daemon is still rather rough, and the qcow
implementation has some bugs. However, it works for light testing and
the occasional luck-assisted heavy testing)
As always, comments welcome and appreciated :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.