* Re: Bonnie++ Burps on XFS
From: Nathan Scott @ 2006-04-06 5:13 UTC (permalink / raw)
To: Kurt Wall; +Cc: LKML, linux-xfs
In-Reply-To: <20060406125756.H1110920@wobbly.melbourne.sgi.com>
On Thu, Apr 06, 2006 at 12:57:56PM +1000, Nathan Scott wrote:
> On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote:
> > I've been using bonnie++ off and on for a long time. Suddenly, it has
> > started failing when run against an XFS filesystem situated on a SATA
> > drive. Here's the output of a run:
>
> [ Please report these things to linux-xfs@oss.sgi.com... ]
>
> > Delete files in sequential order...Bonnie: drastic I/O error (rmdir):
>
> Anything in your system log?
Lemme answer that for you - "no". I've reproduced the problem,
I'll get back to you once I've nutted out whats gone wrong.
Thanks for reporting it.
cheers.
--
Nathan
^ permalink raw reply
* [PATCH] clean up net_rx_action
From: Isaku Yamahata @ 2006-04-06 5:11 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 143 bytes --]
code clean up: net_rx_action()
new_mfn and old_mfn are set in the end half of the function.
but they are not used. remove them.
--
yamahata
[-- Attachment #2: net_rc_action_cleanup.patch --]
[-- Type: text/plain, Size: 1100 bytes --]
changeset: 9545:b33a111ba46659dad195f31b909920e0e7669583
tag: tip
user: yamahata@valinux.co.jp
date: Thu Apr 6 14:07:51 2006 +0900
files: linux-2.6-xen-sparse/drivers/xen/netback/netback.c
description:
code clean up: net_rx_action()
new_mfn and old_mfn are set in the end half of the function.
but they are not used. remove them.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
diff -r 8f7aad20b4a5ba33762db56bb7e5cb94fe24395e -r b33a111ba46659dad195f31b909920e0e7669583 linux-2.6-xen-sparse/drivers/xen/netback/netback.c
--- a/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Wed Apr 5 19:30:02 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Thu Apr 6 14:07:51 2006 +0900
@@ -301,9 +301,6 @@ static void net_rx_action(unsigned long
netif = netdev_priv(skb->dev);
size = skb->tail - skb->data;
- /* Rederive the machine addresses. */
- new_mfn = mcl->args[1] >> PAGE_SHIFT;
- old_mfn = gop->mfn;
atomic_set(&(skb_shinfo(skb)->dataref), 1);
skb_shinfo(skb)->nr_frags = 0;
skb_shinfo(skb)->frag_list = NULL;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Soft lockup on Opteron cpu (2.6.15.4).
From: Andy Davidson @ 2006-04-06 5:11 UTC (permalink / raw)
To: Linux Kernel Mailing List
Hi,
I've just had a nasty oops on an amd64 server. Sadly I wasn't able
to capture the entire stack trace, but I did get :
http://elvis.nosignal.org/~andy/opteron_panic.jpg
Nothing was logged to syslog at the point of the panic, immediately
before the server fell over there was this logged :
Apr 6 01:03:40 freezer kernel: dpti0: Trying to Abort cmd=61901448
Apr 6 01:03:51 freezer kernel: dpti0: Abort cmd not supported
Apr 6 01:03:51 freezer kernel: dpti0: Trying to reset device
Apr 6 01:03:51 freezer kernel: dpti0: Device reset not supported
Apr 6 01:03:51 freezer kernel: dpti0: Bus reset: SCSI Bus 0: tid: 9
Apr 6 01:03:51 freezer kernel: dpti0: Bus reset success.
I understand why a soft lockup might cause the kernel to oops. What
I don't understand is whether the above dpt flap could have caused
the lockup ? I've just upgraded to 2.6.16.1.
Anyone seen this before ? Any more clues ?
cpu is dual AMD Opteron Processor 246.
other hardware :
0000:00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI
(rev 07)
0000:00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC
(rev 05)
0000:00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE
(rev 03)
0000:00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
(rev 02)
0000:00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
0000:00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X
Bridge (rev 12)
0000:00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC
(rev 01)
0000:00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X
Bridge (rev 12)
0000:00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC
(rev 01)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:02:05.0 RAID bus controller: Adaptec (formerly DPT) SmartRAID V
Controller (rev 01)
0000:02:09.0 Ethernet controller: Broadcom Corporation NetXtreme
BCM5704 Gigabit Ethernet (rev 03)
0000:02:09.1 Ethernet controller: Broadcom Corporation NetXtreme
BCM5704 Gigabit Ethernet (rev 03)
0000:03:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111
USB (rev 0b)
0000:03:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111
USB (rev 0b)
0000:03:05.0 Unknown mass storage controller: Silicon Image, Inc.
(formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA
Controller (rev 02)
0000:03:06.0 VGA compatible controller: ATI Technologies Inc Rage XL
(rev 27)
0000:03:08.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro
100] (rev 10)
.config at : http://elvis.nosignal.org/~andy/opteron.config.txt
Using dpt_i2o as had problems with machines of the same hardware
build (Adaptec SR V) when trying i2o_block on opteron around six
months ago.
Thanks for reading this mail,
Andy
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-06 4:52 UTC (permalink / raw)
To: ck; +Cc: Andrew Morton, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <200604061436.16907.kernel@kolivas.org>
On Thursday 06 April 2006 14:36, Con Kolivas wrote:
> On Thursday 06 April 2006 13:40, Andrew Morton wrote:
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> > > > On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > > > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > > > It is possible with a low enough lowmem_reserve ratio to make
> > > > > > zone_watermark_ok fail repeatedly if the lower_zone is small
> > > > > > enough.
> > > > >
> > > > > Is that actually a problem?
> > > >
> > > > Every single call to get_page_from_freelist will call on zone
> > > > reclaim. It seems a problem to me if every call to __alloc_pages will
> > > > do that?
> > >
> > > every call to __alloc_pages of that zone I mean
> >
> > One would need to check with the NUMA guys. zone_reclaim() has a
> > (lame-looking) timer in there to prevent it from doing too much work.
> >
> > That, or I'm missing something. This problem wasn't particularly well
> > described, sorry.
>
> Ah ok. This all came about because I'm trying to honour the lowmem_reserve
> better in swap_prefetch at Nick's request. It's hard to honour a watermark
> that on some configurations is never reached.
Forget that. If the numa people don't care about it I shouldn't touch it. I
thought I was doing something helpful at the source but got no response from
Nick or the the other numa_ids out there so they obviously don't care. I'll
tackle it differently in swap prefetch.
Cheers,
Con
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-06 4:52 UTC (permalink / raw)
To: ck; +Cc: Andrew Morton, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <200604061436.16907.kernel@kolivas.org>
On Thursday 06 April 2006 14:36, Con Kolivas wrote:
> On Thursday 06 April 2006 13:40, Andrew Morton wrote:
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> > > > On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > > > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > > > It is possible with a low enough lowmem_reserve ratio to make
> > > > > > zone_watermark_ok fail repeatedly if the lower_zone is small
> > > > > > enough.
> > > > >
> > > > > Is that actually a problem?
> > > >
> > > > Every single call to get_page_from_freelist will call on zone
> > > > reclaim. It seems a problem to me if every call to __alloc_pages will
> > > > do that?
> > >
> > > every call to __alloc_pages of that zone I mean
> >
> > One would need to check with the NUMA guys. zone_reclaim() has a
> > (lame-looking) timer in there to prevent it from doing too much work.
> >
> > That, or I'm missing something. This problem wasn't particularly well
> > described, sorry.
>
> Ah ok. This all came about because I'm trying to honour the lowmem_reserve
> better in swap_prefetch at Nick's request. It's hard to honour a watermark
> that on some configurations is never reached.
Forget that. If the numa people don't care about it I shouldn't touch it. I
thought I was doing something helpful at the source but got no response from
Nick or the the other numa_ids out there so they obviously don't care. I'll
tackle it differently in swap prefetch.
Cheers,
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: 32-on-64 (x86-64) siginfo corruption
From: David S. Miller @ 2006-04-06 4:41 UTC (permalink / raw)
To: acahalan; +Cc: ak, ak, linux-kernel, linux-arch
In-Reply-To: <787b0d920604052020rdaa5146q58720e7fd82ce0bb@mail.gmail.com>
From: "Albert Cahalan" <acahalan@gmail.com>
Date: Wed, 5 Apr 2006 23:20:07 -0400
> The situation: 32-bit debugger, 32-bit child, 64-bit kernel
>
> The debugger sends an RT signal to the child. (to stop it, with
> a queue and siginfo so that non-debugger signals don't get lost)
> To do this, the debugger uses tgkill().
>
> Later, the debugger checks the child's siginfo_t before discarding
> it. This is to be sure that the child didn't get the RT signal from
> some other source. The debugger fills a siginfo_t with 0xff, then
> fetches siginfo data via ptrace. The data is corrupt:
>
> FIELD 32-ON-64 NORMAL
> si_pid -1 getpid()
> si_uid getpid() getuid()
>
> The "getpid" and "getuid" above are done in the debugger, not in
> the child. The si_code values are SI_TKILL.
>
> Probably the other ports with 32-on-64 support ought to verify
> that this stuff works right.
Ugh, just like PTRACE_GETEVENTMSG we'll need translations for
GETSIGINFO and SETSIGINFO.
I've CC'd linux-arch which is where the port maintainers hang
out and look for postings about issues like this. I mentioned
the PTRACE_GETEVENTMSG issue there just the other day.
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Paul Mackerras @ 2006-04-06 4:37 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, trini
In-Reply-To: <20060402194044.GA866@suse.de>
Olaf Hering writes:
> --- linux-2.6.16-olh.orig/arch/powerpc/Makefile
> +++ linux-2.6.16-olh/arch/powerpc/Makefile
> @@ -107,6 +107,7 @@ endif
> cpu-as-$(CONFIG_PPC64BRIDGE) += -Wa,-mppc64bridge
> cpu-as-$(CONFIG_4xx) += -Wa,-m405
> cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
> +cpu-as-$(CONFIG_6xx) += -mcpu=powerpc
Is this really the right place for this? The cpu-as- thing is really
for assembler options.
Paul.
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-06 4:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: ck, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <20060405204009.3235b021.akpm@osdl.org>
On Thursday 06 April 2006 13:40, Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
> > On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> > > On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > > It is possible with a low enough lowmem_reserve ratio to make
> > > > > zone_watermark_ok fail repeatedly if the lower_zone is small
> > > > > enough.
> > > >
> > > > Is that actually a problem?
> > >
> > > Every single call to get_page_from_freelist will call on zone reclaim.
> > > It seems a problem to me if every call to __alloc_pages will do that?
> >
> > every call to __alloc_pages of that zone I mean
>
> One would need to check with the NUMA guys. zone_reclaim() has a
> (lame-looking) timer in there to prevent it from doing too much work.
>
> That, or I'm missing something. This problem wasn't particularly well
> described, sorry.
Ah ok. This all came about because I'm trying to honour the lowmem_reserve
better in swap_prefetch at Nick's request. It's hard to honour a watermark
that on some configurations is never reached.
Cheers,
Con
^ permalink raw reply
* Re: Respin: [PATCH] mm: limit lowmem_reserve
From: Con Kolivas @ 2006-04-06 4:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: ck, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <20060405204009.3235b021.akpm@osdl.org>
On Thursday 06 April 2006 13:40, Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
> > On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> > > On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > > It is possible with a low enough lowmem_reserve ratio to make
> > > > > zone_watermark_ok fail repeatedly if the lower_zone is small
> > > > > enough.
> > > >
> > > > Is that actually a problem?
> > >
> > > Every single call to get_page_from_freelist will call on zone reclaim.
> > > It seems a problem to me if every call to __alloc_pages will do that?
> >
> > every call to __alloc_pages of that zone I mean
>
> One would need to check with the NUMA guys. zone_reclaim() has a
> (lame-looking) timer in there to prevent it from doing too much work.
>
> That, or I'm missing something. This problem wasn't particularly well
> described, sorry.
Ah ok. This all came about because I'm trying to honour the lowmem_reserve
better in swap_prefetch at Nick's request. It's hard to honour a watermark
that on some configurations is never reached.
Cheers,
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Can't mount /dev/md0 after stopping a synchronization
From: Mike Garey @ 2006-04-06 4:32 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4433FD5C.1050109@steeleye.com>
On 4/5/06, Paul Clements <paul.clements@steeleye.com> wrote:
> Mike Garey wrote:
>
> > I seem to be getting closer.. If I try booting from a kernel without
> > raid1 and md support, but using an initrd with raid1/md modules, then
> > I get the "ALERT! /dev/md0 does not exist. Dropping to a shell!"
> > message. I can't understand why there would be any difference between
> > using a kernel with raid1/md support, or using an initrd image with
> > raid1/md support, but apparently there is. If anyone else has any
>
> Autodetection doesn't occur unless md is built into the kernel -- one of
> the reasons why using autodetection is becoming less and less popular.
> You're probably better off assembling the array from your initrd with
> some invocation of mdadm.
I've since tried building my own initrd using the mkinitramfs script
that comes with debian testing for kernel 2.6.15, as well as the
mkinitramfs from mdadm-2.4. Before, I had only used mkinitramfs that
came with debian testing, and it didn't seem to include the mdadm
binary into the image, which would explain why it wasn't able to mount
the root filesystem (it also tries to execute the command "/sbin/mdrun
dev", which I guess should start the RAID array, but /sbin/mdrun
doesn't exist either - seems the built in mkinitramfs script doesn't
really work exactly as it should - either that, or I'm making a
mistake somewhere). Anyways, after booting using my initramfs image
(and failling to mount /dev/md0), I was dropped into busybox and tried
the following:
/ # mdadm -Acpartitions --super-minor=0 --auto=part /dev/mda
md: md_d0 stopped.
md: bind<hdc1>
raid: raid set md_d0 active with 1 out of 2 mirrors
mdadm: /dev/mda has been started with 1 drive (out of 2).
/ # mount /dev/mda /root
EXT2-fs warning (device md_d0): ext2_fill_super: mounting ext3
filesystem as ext2
/# mount
none on /sys type sysfs (rw)
non on /proc type proc (rw,nodiratime)
udev on /dev type tmpfs (rw)
/dev/mda on /root type ext2 (rw,nogrpid)
so it seems with a little bit of tweaking, I'll be able to modify the
scripts to get /dev/md0 to mount as the root file system. The only
thing that bothers me is the "EXT2-fs warning" about having the ext3
filesystem mounted as ext2.. Does anybody know why this is happening,
or how to fix this? Also, having mounted the filesystem as ext2, will
I have caused any damage to it? And should I be mounting my RAID
device as /dev/mda or /dev/md0?
On 4/5/06, Jim Klimov <klimov@2ka.mipt.ru> wrote:
> Hello Mike,
>
> I'm afraid I haven't seen your first messages in detail. Sorry, if I
> repeat the lines you already know by heart ;)
>
> Nevertheless, do you by chance have the ability to rebuild your
> kernel, or are you keen on making MD work from initrd and some stock
> kernel?
right now I'm using a custom built kernel with md and raid1 built into
it and it works fine (although I get the same EXT2-fs warning as with
the initramfs image early on in the boot process, but it seems to end
up being mounted as ext3 when the system finally boots). As I
mentioned above, I'm now trying to get the initramfs version working,
since it'd be nice to have a solution that works with the standard
prepackaged kernel.
> If a custom kernel is ok, link the raid1 driver statically. In this
> case, if the root submirrors are primary partitions flagged with 0xfd
> filesystem type, the kernel will assemble these partitions to a mirror
> before mounting.
>
> You can also try the raid1 driver's parameters on kernel command line
> to force md-device naming and components, i.e.
> ... root=/dev/md0 md=0,/dev/hda1,/dev/hdc1
>
> And in case of mirroring i think you should always be able to mount
> the filesystems as they are, i.e.
> ... root=/dev/hda1 ro
>
> A pitfall is there, that /etc/fstab may require mounting other FSes
> from metadevices, not partitions. And if you mount read-write, then
> your submirrors will be out of sync and that's undetected by raid
> driver.
^ permalink raw reply
* Re: [patch 2.6.16-mm2 10/9] sched throttle tree extract - kill interactive task feedback loop
From: Con Kolivas @ 2006-04-06 4:29 UTC (permalink / raw)
To: Mike Galbraith
Cc: Ingo Molnar, Andrew Morton, lkml, Peter Williams, Nick Piggin
In-Reply-To: <1144296619.7436.8.camel@homer>
On Thursday 06 April 2006 14:10, Mike Galbraith wrote:
> On Thu, 2006-04-06 at 09:15 +1000, Con Kolivas wrote:
> > On Thursday 06 April 2006 03:38, Mike Galbraith wrote:
> > > - if (!rt_task(next) && interactive_sleep(next->sleep_type)) {
> > > + if (!TASK_INTERACTIVE(next) && interactive_sleep(next->sleep_type)) {
> >
> > You can't remove that rt_task check from there can you? We shouldn't ever
> > requeue a rt task.
>
> RT tasks are always interactive aren't they? (I'll check)
No, they're always equal to their static_prio. This rt_task check was added
originally because it was found to inappropriately be requeueing SCHED_FIFO
tasks.
Cheers,
Con
^ permalink raw reply
* Re: Q on audit, audit-syscall
From: Valdis.Kletnieks @ 2006-04-06 4:24 UTC (permalink / raw)
To: Herbert Rosmanith; +Cc: Kyle Moffett, Robin Holt, linux-kernel
In-Reply-To: <200604052147.k35LlOpK010229@wildsau.enemy.org>
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
On Wed, 05 Apr 2006 23:47:24 +0200, Herbert Rosmanith said:
> anyway, the manpage describes how auditd/libaudit works - not how it has been
> implemented/how it communicates with the kernel.
> I want to know how it works "under the hood", not just how to use it.
One thing that's not at all clear from casual reading of the source code
of either the kernel or the userspace, or most of the existing docs...
The audit facility is *very much* an after-the-fact logging - there are a
few places where the code jumps through very odd hoops to deal with the fact
that by the time an actual notification is generated, the entire process that
triggered the event could be *gone*, completely and totally.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: RT task scheduling
From: Peter Williams @ 2006-04-06 4:19 UTC (permalink / raw)
To: Darren Hart
Cc: linux-kernel, Ingo Molnar, Thomas Gleixner, Stultz, John,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604052025.05679.darren@dvhart.com>
Darren Hart wrote:
> My last mail specifically addresses preempt-rt, but I'd like to know people's
> thoughts regarding this issue in the mainline kernel. Please see my previous
> post "realtime-preempt scheduling - rt_overload behavior" for a testcase that
> produces unpredictable scheduling results.
>
> Part of the issue here is to define what we consider "correct behavior" for
> SCHED_FIFO realtime tasks. Do we (A) need to strive for "strict realtime
> priority scheduling" where the NR_CPUS highest priority runnable SCHED_FIFO
> tasks are _always_ running? Or do we (B) take the best effort approach with
> an upper limit RT priority imbalances, where an imbalance may occur (say at
> wakeup or exit) but will be remedied within 1 tick. The smpnice patches
> improve load balancing, but don't provide (A).
>
> More details in the previous mail...
I'm currently researching some ideas to improve smpnice that may help in
this situation. The basic idea is that as well as trying to equally
distribute the weighted load among the groups/queues we should also try
to achieve equal "average load per task" for each group/queue. (As well
as helping with problems such as yours, this will help to restore the
"equal distribution of nr_running" amongst groups/queues aim that is
implicit without smpnice due to the fact that load is just a smoothed
version of nr_running.)
In find_busiest_group(), I think that load balancing in the case where
*imbalance is greater than busiest_load_per_task will tend towards this
result and also when *imbalance is less than busiest_load_per_task AND
busiest_load_per_task is less than this_load_per_task. However, in the
case where *imbalance is less than busiest_load_per_task AND
busiest_load_per_task is greater than this_load_per_task this will not
be the case as the amount of load moved from "busiest" to "this" will be
less than or equal to busiest_load_per_task and this will actually
increase the value of busiest_load_per_task. So, although it will
achieve the aim of equally distributing the weighted load, it won't help
the second aim of equal "average load per task" values for groups/queues.
The obvious way to fix this problem is to alter the code so that more
than busiest_load_per_task is moved from "busiest" to "this" in these
cases while at the same time ensuring that the imbalance between their
loads doesn't get any bigger. I'm working on a patch along these lines.
Changes to find_idlest_group() and try_to_wake_up() taking into account
the "average load per task" on the candidate queues/groups as well as
their weighted loads may also help and I'll be looking at them as well.
It's not immediately obvious to me how this can be done so any ideas
would be welcome. It will likely involve taking the load weight of the
waking task into account as well.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Junio C Hamano @ 2006-04-06 4:13 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200604050624h13ebd8deg241ae98cef1f5a74@mail.gmail.com>
"Kees-Jan Dijkzeul" <k.j.dijkzeul@gmail.com> writes:
> I'm trying to get Git to manage my companies source tree. We're
> writing software for digital TV sets. Anyway, the archive is about 5Gb
> in size and contains binaries, zip files, excel sheets meeting minutes
> and whatnot. So it doesn't compress very well. The 1.5Gb pack file
> hardly contains any history at all (five commits or so). On the flip
> side, for now I'll be the only one adding to the archive, so at least
> it will not grow that fast ;-)
>
> Anyway, to reconstitute the tree, I need very nearly the entire pack,
> so limiting the pack size won't do much good, as git will still try to
> allocate a total of 1.5Gb memory (which, unfortunately, isn't there
> :-)
Right now we LRU the pack files and evict older ones when we
mmap too many, but the unit of eviction is the whole file, so it
would not help the case like yours at all. It might be possible
to mmap only part of a packfile, but it would involve fairly
major surgery to sha1_file.c.
^ permalink raw reply
* Re: [patch 2.6.16-mm2 10/9] sched throttle tree extract - kill interactive task feedback loop
From: Mike Galbraith @ 2006-04-06 4:10 UTC (permalink / raw)
To: Con Kolivas; +Cc: Ingo Molnar, Andrew Morton, lkml, Peter Williams, Nick Piggin
In-Reply-To: <200604060915.07036.kernel@kolivas.org>
On Thu, 2006-04-06 at 09:15 +1000, Con Kolivas wrote:
> On Thursday 06 April 2006 03:38, Mike Galbraith wrote:
> > Greetings,
> >
> > The patch below stops interactive tasks from feeding off each other
> > during round-robin.
> >
> > With this 10th patch in place, a busy server with _default_ throttle
> > settings (ie tunables may now be mostly unneeded) looks like this:
>
> > --- linux-2.6.16-mm2/kernel/sched.c-9.export_tunables 2006-03-31
> > 13:37:09.000000000 +0200 +++ linux-2.6.16-mm2/kernel/sched.c 2006-04-05
> > 19:22:01.000000000 +0200 @@ -3480,7 +3480,7 @@ go_idle:
> > queue = array->queue + idx;
> > next = list_entry(queue->next, task_t, run_list);
> >
> > - if (!rt_task(next) && interactive_sleep(next->sleep_type)) {
> > + if (!TASK_INTERACTIVE(next) && interactive_sleep(next->sleep_type)) {
>
> You can't remove that rt_task check from there can you? We shouldn't ever
> requeue a rt task.
RT tasks are always interactive aren't they? (I'll check)
Anyway, this is definitely a large part of the problem with the ssh to
busy server, but a complete block of interactive tasks isn't quite the
right solution. With an SMP kernel, my desktop appeared to be fine, but
a quick spin with UP kernel isn't looking quite so good. This needs
more investigation.
-Mike
^ permalink raw reply
* Re: ACPI Compile error in current git (pci.h)
From: Nigel Cunningham @ 2006-04-06 4:09 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-acpi
In-Reply-To: <20060406035012.GB26601@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
Hi Greg.
On Thursday 06 April 2006 13:50, Greg KH wrote:
> On Fri, Mar 24, 2006 at 02:37:18PM +1000, Nigel Cunningham wrote:
> > Hi again.
> >
> > On Friday 24 March 2006 14:04, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > Current git produces the following compile error (x86_64 uniprocessor
> > > compile):
> > >
> > > arch/x86_64/pci/mmconfig.c:152: error: conflicting types for
> > > ???pci_mmcfg_init??? arch/i386/pci/pci.h:85: error: previous
> > > declaration of ???pci_mmcfg_init??? was here make[1]: ***
> > > [arch/x86_64/pci/mmconfig.o] Error 1 make: *** [arch/x86_64/pci] Error
> > > 2
> > >
> > > I haven't found out yet how the i386 file is getting included, but I
> > > can say that git compiled fine last night.
> >
> > Got the answer to this bit - it is included via the Makefile in the
> > directory setting a -I flag, and the file including "pci.h".
>
> Does this still happen for 2.6.17-rc1?
>
> thanks,
>
> greg k-h
No, it's fixed. I figured out the cause a little later the same day, and so
did someone else (don't recall the name now). A patch has been merged.
Regards,
Nigel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.16-rt11 and low-latency audio xruns (interrupt latency problem?)
From: Valin, Jean-Marc (ICT Centre, Marsfield) @ 2006-04-06 4:09 UTC (permalink / raw)
To: Lee Revell; +Cc: linux-kernel
In-Reply-To: <1143699565.7328.8.camel@theorix.CeNTIE.NET.au>
On Thu, 2006-03-30 at 17:19 +1100, Valin, Jean-Marc (ICT Centre,
Marsfield) wrote:
> > It's possible that your hardware simply isn't capable of this and you'll
> > have to get a multichannel soundcard (more channels means you can use a
> > smaller buffer before hitting the lower limit of a PCI transfer) or use
> > a period of 128 samples or more.
Could you give me more info on that PCI transfer limit? I couldn't find
any reference to that on the web. Also, any way to see if that's the
real cause of the problem. I've been doing some experiments and noticed
that the percentage or xruns I get is almost independent of the period
size, which is a little odd. Any idea?
Jean-Marc
^ permalink raw reply
* Re: [PATCH] modules_install must not remove existing modules
From: Valdis.Kletnieks @ 2006-04-06 4:04 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Andreas Gruenbacher, linux-kernel
In-Reply-To: <20060405221229.GA8972@mars.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
On Thu, 06 Apr 2006 00:12:29 +0200, Sam Ravnborg said:
> I see no way to detect when it is OK to remove or not, so in the
> principle of least suprise I prefer having the removal unconditional for
> normal kernel builds, and no removal for external modules.
That sounds workable to me.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* [PATCH]User manual update for VNC mouse issue of full virtulization Guest.
From: You, Yongkang @ 2006-04-06 3:55 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 4252 bytes --]
Hi,
Although VNC mouse issue has been fixed by Dugger, Donald D , it still
need some extra configurations. This patch update the user manual
appendix. Then user can follow this guide to let his mouse working
properly in a VNC window.
And, it also adds 'pae' configuration introduction for full
virtulization Guest.
Best Regards,
Yongkang
Signed-off-by: You, Yongkang <yongkang.you@intel.com>
Signed-off-by: Dugger, Donald D <donald.d.dugger@intel.com>
--- a/docs/src/user.tex 2006-04-05 11:32:18.000000000 +0800
+++ b/docs/src/user.tex 2006-04-06 11:19:09.000000000 +0800
@@ -2052,7 +2052,7 @@
If the dev86 package is not available on the x86\_64 distribution, you
can inst all the i386 version of it. The dev86 rpm package for various
distributions can be found at {\scriptsize {\tt
http://www.rpmfind.net/linux/rpm2html/search.php?q uery=dev86
\&submit=Search}} \\
-LibVNCServer & The unmodified guest's VGA display, keyboard, and mouse
are virt ualized using the vncserver library provided by this package.
You can get the so urces of libvncserver from {\small {\tt
http://sourceforge.net/projects/libvncse rver}}. Build and install the
sources on the build system to get the libvncserve r library. The 0.8pre
version of libvncserver is currently working well with Xen .\\
+LibVNCServer & The unmodified guest's VGA display, keyboard, and mouse
can be v irtualized by the vncserver library. You can get the sources of
libvncserver fro m {\small {\tt
http://sourceforge.net/projects/libvncserver}}. Build and install the
sources on the build system to get the libvncserver library. There is a
sig nificant performance degradation in 0.8 version. The current sources
in the CVS tree have fixed this degradation. So it is highly recommended
to download the la test CVS sources and install them.\\
SDL-devel, SDL & Simple DirectMedia Layer (SDL) is another way of
virtualizing the unmodified guest console. It provides an X window for
the guest console.
@@ -2077,6 +2077,8 @@
apic & Enable VMX guest APIC, default=0 (disabled)\\
+pae & Enable VMX guest PAE, default=0 (disabled)\\
+
vif & Optionally defines MAC address and/or bridge for the network
interfac es. Random MACs are assigned if not given. {\small {\tt
type=ioemu}} means ioemu is used to virtualize the VMX NIC. If no type
is specified, vbd is used, as wit h paravirtualized guests.\\
disk & Defines the disk devices you want the domain to have access to,
and what you want them accessible as. If using a physical device as the
VMX guest's disk , each disk entry is of the form
@@ -2229,6 +2231,30 @@
In the default configuration, VNC is on and SDL is off. Therefore VNC
windows w ill open when VMX guests are created. If you want to use SDL
to create VMX guest s, set {\small {\tt sdl=1}} in your VMX
configuration file. You can also turn of f VNC by setting {\small {\tt
vnc=0}}.
+\subsection{Use mouse in VNC window}
+The default PS/2 mouse will not work properly in VMX by a VNC window.
Summagrap hics mouse emulation does work in this environment. A
Summagraphics mouse can be enabled by reconfiguring 2 services:
+
+{\small {\tt 1. General Purpose Mouse (GPM). The GPM daemon is
configured in di fferent ways in different Linux distributions. On a
Redhat distribution, this is accomplished by changing the file
`/etc/sysconfig/mouse' to have the following: \\
+MOUSETYPE="summa"\\
+XMOUSETYPE="SUMMA"\\
+DEVICE=/dev/ttyS0\\
+\\
+2. X11. For all Linux distributions, change the Mouse0 stanza in
`/etc/X11/xorg .conf' to:\\
+Section "InputDevice"\\
+Identifier "Mouse0"\\
+Driver "summa"\\
+Option "Device" "/dev/ttyS0"\\
+Option "InputFashion" "Tablet"\\
+Option "Mode" "Absolute"\\
+Option "Name" "EasyPen"\\
+Option "Compatible" "True"\\
+Option "Protocol" "Auto"\\
+Option "SendCoreEvents" "on"\\
+Option "Vendor" "GENIUS"\\
+EndSection}}
+
+If the Summagraphics mouse isn't the default mouse, you can manually
kill 'gpm' and restart it with the command "gpm -m /dev/ttyS0 -t
summa". Note that Summagr aphics mouse makes no sense in an SDL window
and is therefore not available in t his environment.
+
\subsection{Destroy VMX guests}
VMX guests can be destroyed in the same way as can paravirtualized
guests. We r ecommend that you type the command
[-- Attachment #2: user_manual.patch --]
[-- Type: text/x-patch, Size: 3778 bytes --]
--- a/docs/src/user.tex 2006-04-05 11:32:18.000000000 +0800
+++ b/docs/src/user.tex 2006-04-06 11:19:09.000000000 +0800
@@ -2052,7 +2052,7 @@
If the dev86 package is not available on the x86\_64 distribution, you can install the i386 version of it. The dev86 rpm package for various distributions can be found at {\scriptsize {\tt http://www.rpmfind.net/linux/rpm2html/search.php?query=dev86\&submit=Search}} \\
-LibVNCServer & The unmodified guest's VGA display, keyboard, and mouse are virtualized using the vncserver library provided by this package. You can get the sources of libvncserver from {\small {\tt http://sourceforge.net/projects/libvncserver}}. Build and install the sources on the build system to get the libvncserver library. The 0.8pre version of libvncserver is currently working well with Xen.\\
+LibVNCServer & The unmodified guest's VGA display, keyboard, and mouse can be virtualized by the vncserver library. You can get the sources of libvncserver from {\small {\tt http://sourceforge.net/projects/libvncserver}}. Build and install the sources on the build system to get the libvncserver library. There is a significant performance degradation in 0.8 version. The current sources in the CVS tree have fixed this degradation. So it is highly recommended to download the latest CVS sources and install them.\\
SDL-devel, SDL & Simple DirectMedia Layer (SDL) is another way of virtualizing the unmodified guest console. It provides an X window for the guest console.
@@ -2077,6 +2077,8 @@
apic & Enable VMX guest APIC, default=0 (disabled)\\
+pae & Enable VMX guest PAE, default=0 (disabled)\\
+
vif & Optionally defines MAC address and/or bridge for the network interfaces. Random MACs are assigned if not given. {\small {\tt type=ioemu}} means ioemu is used to virtualize the VMX NIC. If no type is specified, vbd is used, as with paravirtualized guests.\\
disk & Defines the disk devices you want the domain to have access to, and what you want them accessible as. If using a physical device as the VMX guest's disk, each disk entry is of the form
@@ -2229,6 +2231,30 @@
In the default configuration, VNC is on and SDL is off. Therefore VNC windows will open when VMX guests are created. If you want to use SDL to create VMX guests, set {\small {\tt sdl=1}} in your VMX configuration file. You can also turn off VNC by setting {\small {\tt vnc=0}}.
+\subsection{Use mouse in VNC window}
+The default PS/2 mouse will not work properly in VMX by a VNC window. Summagraphics mouse emulation does work in this environment. A Summagraphics mouse can be enabled by reconfiguring 2 services:
+
+{\small {\tt 1. General Purpose Mouse (GPM). The GPM daemon is configured in different ways in different Linux distributions. On a Redhat distribution, this is accomplished by changing the file `/etc/sysconfig/mouse' to have the following:\\
+MOUSETYPE="summa"\\
+XMOUSETYPE="SUMMA"\\
+DEVICE=/dev/ttyS0\\
+\\
+2. X11. For all Linux distributions, change the Mouse0 stanza in `/etc/X11/xorg.conf' to:\\
+Section "InputDevice"\\
+Identifier "Mouse0"\\
+Driver "summa"\\
+Option "Device" "/dev/ttyS0"\\
+Option "InputFashion" "Tablet"\\
+Option "Mode" "Absolute"\\
+Option "Name" "EasyPen"\\
+Option "Compatible" "True"\\
+Option "Protocol" "Auto"\\
+Option "SendCoreEvents" "on"\\
+Option "Vendor" "GENIUS"\\
+EndSection}}
+
+If the Summagraphics mouse isn't the default mouse, you can manually kill 'gpm' and restart it with the command "gpm -m /dev/ttyS0 -t summa". Note that Summagraphics mouse makes no sense in an SDL window and is therefore not available in this environment.
+
\subsection{Destroy VMX guests}
VMX guests can be destroyed in the same way as can paravirtualized guests. We recommend that you type the command
[-- Attachment #3: 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: ACPI Compile error in current git (pci.h)
From: Greg KH @ 2006-04-06 3:50 UTC (permalink / raw)
To: Nigel Cunningham; +Cc: linux-kernel, linux-acpi
In-Reply-To: <200603241437.26633.ncunningham@cyclades.com>
On Fri, Mar 24, 2006 at 02:37:18PM +1000, Nigel Cunningham wrote:
> Hi again.
>
> On Friday 24 March 2006 14:04, Nigel Cunningham wrote:
> > Hi.
> >
> > Current git produces the following compile error (x86_64 uniprocessor
> > compile):
> >
> > arch/x86_64/pci/mmconfig.c:152: error: conflicting types for
> > ???pci_mmcfg_init??? arch/i386/pci/pci.h:85: error: previous declaration of
> > ???pci_mmcfg_init??? was here make[1]: *** [arch/x86_64/pci/mmconfig.o] Error 1
> > make: *** [arch/x86_64/pci] Error 2
> >
> > I haven't found out yet how the i386 file is getting included, but I
> > can say that git compiled fine last night.
>
> Got the answer to this bit - it is included via the Makefile in the directory
> setting a -I flag, and the file including "pci.h".
Does this still happen for 2.6.17-rc1?
thanks,
greg k-h
^ permalink raw reply
* Re: [linux-lvm] Bad disk removal
From: Fredrik Tolf @ 2006-04-06 3:51 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <44340F46.5040000@volved.com>
On Wed, 2006-04-05 at 14:41 -0400, Barnaby Claydon wrote:
> Hey all,
>
> So after lots of scans and log review, turns out 1 of the 8 IDE disks in
> my LVM is bad. (I know, IDE, yeahyeah...)
When this happened to me, I got a replacement drive as large as that
drive, and used dd to copy the PV data bit-by-bit to the new disk, and
then zeroed the sectors corresponding to the old bad sectors. It worked
fairly well, but the bad sectors were probably only file data blocks for
me.
As far as I managed to find out, pvmove will not handle bad sectors at
all, and abort when it finds any. It would be great if anyone could
correct me on that, though...
Fredrik Tolf
^ permalink raw reply
* [PATCH] [vTPM] hotplug script change
From: Stefan Berger @ 2006-04-06 3:48 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
This removes some unnecessary code from the vTPM hotplug scripts.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
[-- Attachment #2: vtpm-hotplug.diff --]
[-- Type: text/x-patch, Size: 547 bytes --]
Index: root/xen-unstable.hg/tools/examples/vtpm-common.sh
===================================================================
--- root.orig/xen-unstable.hg/tools/examples/vtpm-common.sh
+++ root/xen-unstable.hg/tools/examples/vtpm-common.sh
@@ -261,12 +261,6 @@ function vtpm_create_instance () {
if [ "$REASON" == "create" ]; then
vtpm_reset $instance
- elif [ "$REASON" == "resume" ]; then
- vtpm_setup $instance
- else
- #default case for 'now'
- #vtpm_reset $instance
- true
fi
xenstore_write $XENBUS_PATH/instance $instance
}
[-- Attachment #3: 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: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
From: Daniel Phillips @ 2006-04-06 3:42 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060406015636.GE6924@ccure.user-mode-linux.org>
Jeff Dike wrote:
> Yeah, it's a bit non-obvious what 0 means in the twisty little maze of
> GFP_ flags.
>
> However, I do want to push the system into reclaim later. It looks
> like the only difference between 0 and GFP_ATOMIC is the use of
> emergency pools, which I don't really want to exercise anyway.
>
> ...This look OK to you?...
>
> + /* 0 means don't wait (like GFP_ATOMIC) and
> + * don't dip into emergency pools (unlike
> + * GFP_ATOMIC).
> + */
> + new = kmalloc(sizeof(*new), 0);
If you have a believable use for gfp_mask=0 then why not add GFP_NOWAIT or some
such to gfp.h?
Regards,
Daniel
^ permalink raw reply
* Re: [uml-devel] Re: [PATCH 12/16] UML - Memory hotplug
From: Daniel Phillips @ 2006-04-06 3:42 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060406015636.GE6924@ccure.user-mode-linux.org>
Jeff Dike wrote:
> Yeah, it's a bit non-obvious what 0 means in the twisty little maze of
> GFP_ flags.
>
> However, I do want to push the system into reclaim later. It looks
> like the only difference between 0 and GFP_ATOMIC is the use of
> emergency pools, which I don't really want to exercise anyway.
>
> ...This look OK to you?...
>
> + /* 0 means don't wait (like GFP_ATOMIC) and
> + * don't dip into emergency pools (unlike
> + * GFP_ATOMIC).
> + */
> + new = kmalloc(sizeof(*new), 0);
If you have a believable use for gfp_mask=0 then why not add GFP_NOWAIT or some
such to gfp.h?
Regards,
Daniel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&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: Respin: [PATCH] mm: limit lowmem_reserve
From: Andrew Morton @ 2006-04-06 3:40 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck, nickpiggin, linux-kernel, linux-mm
In-Reply-To: <200604061258.40487.kernel@kolivas.org>
Con Kolivas <kernel@kolivas.org> wrote:
>
> On Thursday 06 April 2006 12:55, Con Kolivas wrote:
> > On Thursday 06 April 2006 12:43, Andrew Morton wrote:
> > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > It is possible with a low enough lowmem_reserve ratio to make
> > > > zone_watermark_ok fail repeatedly if the lower_zone is small enough.
> > >
> > > Is that actually a problem?
> >
> > Every single call to get_page_from_freelist will call on zone reclaim. It
> > seems a problem to me if every call to __alloc_pages will do that?
>
> every call to __alloc_pages of that zone I mean
>
One would need to check with the NUMA guys. zone_reclaim() has a
(lame-looking) timer in there to prevent it from doing too much work.
That, or I'm missing something. This problem wasn't particularly well
described, sorry.
^ 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.