* Re: [PATCH] cpuset: remove extra cpuset_zone_allowed check in __alloc_pages
From: Paul Jackson @ 2006-05-23 6:35 UTC (permalink / raw)
To: Chris Wright; +Cc: akpm, chrisw, clameter, linux-kernel
In-Reply-To: <20060523063500.GB18769@moss.sous-sol.org>
Thanks, Chris.
Signed-off-by: Paul Jackson <pj@sgi.com>
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* [PATCH] cpuset: remove extra cpuset_zone_allowed check in __alloc_pages
From: Chris Wright @ 2006-05-23 6:35 UTC (permalink / raw)
To: akpm; +Cc: Paul Jackson, chrisw, Christoph Lameter, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0605221925350.7272@schroedinger.engr.sgi.com>
This is redundant with check in wakeup_kswapd.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
mm/page_alloc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -951,8 +951,7 @@ restart:
goto got_pg;
do {
- if (cpuset_zone_allowed(*z, gfp_mask|__GFP_HARDWALL))
- wakeup_kswapd(*z, order);
+ wakeup_kswapd(*z, order);
} while (*(++z));
/*
^ permalink raw reply
* Re: ASUS A8V Deluxe, x86_64
From: Aaron Gyes @ 2006-05-23 6:10 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <8E8F647D7835334B985D069AE964A4F7028FDBE8@ECQCMTLMAIL1.quebec.int.ec.gc.ca>
Hi, I have the latest libata stuff from git as of a couple days ago and all
appeared to be working, my Plextor PX716-SA appeared to be detected, and I could
read from it fine. But if I burn CDs, no matter what I do, burnfree on, burnfree
off, 4x, I get corruption, with either total coasters or readable filesystems
with md5s that are all off. I'm not sure what I could possibly be doing wrong, I
know it shouldn't be this difficult to write a CD. I also have a Asus A8V.
Here's some cdrecord output, I do notice some things which may or may not be as
bad as they look:
cdrecord stderr: cdrecord: Warning: Running on Linux-2.6.17-rc4-floam1
cdrecord stderr: cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord stderr: cdrecord: If you have unexpected problems, please try Linux-2.4
or Solaris.
cdrecord stderr: scsidev: '/dev/scd0'
cdrecord stderr: devname: '/dev/scd0'
cdrecord stderr: scsibus: -2 target: -2 lun: -2
cdrecord stderr: Warning: Open by 'devname' is unintentional and not supported.
cdrecord stderr: Linux sg driver version: 3.5.27
cdrecord stderr: cdrecord: Warning: using inofficial version of libscg (debian-0
.8debian2 '@(#)scsitransp.c 1.91 04/06/17 Copyright 1988,1995,2000-2004 J. S
chilling').
cdrecord stderr: SCSI buffer size: 64512
cdrecord stderr: cdrecord: This version of cdrecord does not include DVD-R/DVD-R
W support code.
cdrecord stderr: cdrecord: See /usr/share/doc/cdrecord/README.DVD.Debian for det
ails on DVD support.
cdrecord stdout: Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 199
5-2004 Joerg Schilling
cdrecord stdout: NOTE: this version of cdrecord is an inofficial (modified) rele
ase of cdrecord
cdrecord stdout: and thus may have bugs that are not present in the origin
al version.
cdrecord stdout: Please send bug reports and support requests to <cdrtools
@packages.debian.org>.
cdrecord stdout: The original author should not be bothered with problems
of this version.
cdrecord stdout:
cdrecord stdout: TOC Type: 1 = CD-ROM
cdrecord stdout: Using libscg version 'debian-0.8debian2'.
cdrecord stdout: Driveropts: 'burnfree'
cdrecord stdout: atapi: 1
cdrecord stdout: Device type : Removable CD-ROM
cdrecord stdout: Version : 5
cdrecord stdout: Response Format: 2
cdrecord stdout: Capabilities :
cdrecord stdout: Vendor_info : 'PLEXTOR '
cdrecord stdout: Identifikation : 'DVDR PX-716A '
cdrecord stdout: Revision : '1.08'
cdrecord stdout: Device seems to be: Generic mmc2 DVD-R/DVD-RW.
cdrecord stdout: Current: 0x0009
cdrecord stdout: Profile: 0x002B
cdrecord stdout: Profile: 0x001B
cdrecord stdout: Profile: 0x001A
cdrecord stdout: Profile: 0x0015
cdrecord stdout: Profile: 0x0014
cdrecord stdout: Profile: 0x0013
cdrecord stdout: Profile: 0x0011
cdrecord stdout: Profile: 0x0010
cdrecord stdout: Profile: 0x000A
cdrecord stdout: Profile: 0x0009 (current)
cdrecord stdout: Profile: 0x0008
cdrecord stdout: Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
cdrecord stdout: Driver flags : MMC-3 SWABAUDIO BURNFREE VARIREC GIGAREC FORCE
SPEED SPEEDREAD SINGLESESSION HIDECDR
cdrecord stdout: Supported modes: TAO SAO SAO/R96P SAO/R96R RAW/R96R
cdrecord stdout: Drive buf size : 4802784 = 4690 KB
cdrecord stdout: Drive DMA Speed: 22958 kB/s 130x CD 16x DVD
cdrecord stdout: FIFO size : 16777216 = 16384 KB
cdrecord stdout: Track 01: data 100 MB
cdrecord stdout: Total size: 115 MB (11:25.48) = 51411 sectors
cdrecord stdout: Lout start: 115 MB (11:27/36) = 51411 sectors
cdrecord stdout: Current Secsize: 2048
cdrecord stdout: ATIP info from disk:
cdrecord stdout: Indicated writing power: 4
cdrecord stdout: Is not unrestricted
cdrecord stdout: Is not erasable
cdrecord stdout: Disk sub type: Medium Type A, low Beta category (A-) (2)
cdrecord stdout: ATIP start of lead in: -12508 (97:15/17)
cdrecord stdout: ATIP start of lead out: 359845 (79:59/70)
cdrecord stdout: Disk type: Short strategy type (Phthalocyanine or similar)
cdrecord stdout: Manuf. index: 22
cdrecord stdout: Manufacturer: Ritek Co.
cdrecord stdout: Single session is OFF.
cdrecord stdout: Hide CDR is OFF.
cdrecord stdout: Speed-Read is OFF.
cdrecord stdout: GigaRec is off.
cdrecord stdout: Blocks total: 359845 Blocks current: 359845 Blocks remaining: 3
08434
cdrecord stdout: Forcespeed is OFF.
cdrecord stdout: Power-Rec is ON.
cdrecord stdout: Power-Rec write speed: 48x (recommended)
cdrecord stdout: Starting to write CD/DVD at speed 16 in real SAO mode for singl
e session.
cdrecord stdout: Last chance to quit, starting real write 0 seconds.
Operation starts.
cdrecord stderr: cdrecord: Input/output error. mode select g1: scsi sendcmd: no
error
cdrecord stdout: Waiting for reader process to fill input buffer ... input
buffer ready.
cdrecord stderr: CDB: 55 10 00 00 00 00 00 00 3C 00
cdrecord stdout: BURN-Free is ON.
cdrecord stderr: status: 0x2 (CHECK CONDITION)
cdrecord stdout: Performing OPC...
cdrecord stderr: Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 26 00 00 00
cdrecord stderr: Sense Key: 0x5 Illegal Request, Segment 0
cdrecord stderr: Sense Code: 0x26 Qual 0x00 (invalid field in parameter list)
Fru 0x0
cdrecord stderr: Sense flags: Blk 0 (not valid)
cdrecord stderr: resid: 60
cdrecord stderr: cmd finished after 0.000s timeout 200s
cdrecord stderr: cdrecord: Warning: using default CD write parameter data.
cdrecord stderr: Mode Select Data 00 10 00 00 05 32 41 04 08 10 00 00 00 00 00
00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cdrecord stderr: cdrecord: Cannot set up 2nd set of driver options.
cdrecord stdout: Sending CUE sheet...
cdrecord stdout: Writing pregap for track 1 at -150
cdrecord stdout: Starting new track at sector: 0
cdrecord stdout: Track 01: 100 of 100 MB written (fifo 100%) [buf 99%] 16.9x.
cdrecord stdout: Track 01: Total bytes read/written: 105289728/105289728 (51411
sectors).
cdrecord stdout: Writing time: 64.725s
cdrecord stdout: Average write speed 12.7x.
cdrecord stdout: Min drive buffer fill was 99%
cdrecord stdout: Fixating...
cdrecord stdout: Fixating time: 7.316s
cdrecord stdout: Last selected write speed: 16x
cdrecord stderr: cdrecord: fifo had 1659 puts and 1659 gets.
cdrecord stdout: Max media write speed: 48x
cdrecord stderr: cdrecord: fifo was 0 times empty and 1403 times full, min fill
was 99%.
cdrecord stdout: Last actual write speed: 16x
^ permalink raw reply
* i386 Kconfig options out of order
From: Keith Owens @ 2006-05-23 6:10 UTC (permalink / raw)
To: linux-kernel
Options NUMA and EFI in arch/i386/Kconfig depend on ACPI but they
appear before the ACPI option. make oldconfig with no initial setting
for CONFIG_ACPI will prompt for these options, but if you then say No
to CONFIG_ACPI the options will silently be turned off. Conversely if
you turn on CONFIG_ACPI you do not get prompted for the options that
are out of order.
^ permalink raw reply
* Re: 2.6.17-rc4 md lock held at task exit
From: Neil Brown @ 2006-05-23 6:05 UTC (permalink / raw)
To: Keith Owens; +Cc: mingo, linux-kernel
In-Reply-To: <9193.1148363807@kao2.melbourne.sgi.com>
On Tuesday May 23, kaos@ocs.com.au wrote:
>
> Finally got some time to test this. The problem was reproducable and
> the patch fixed it.
>
> Acked-by: Keith Owens <kaos@ocs.com.au>
Thanks. I'll make sure it goes in.
NeilBrown
^ permalink raw reply
* Re: cpu hotplug sleeping from invalid context
From: Ashok Raj @ 2006-05-23 5:56 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel, akpm, jacob.shin
In-Reply-To: <20060522183534.GA8920@redhat.com>
On Mon, May 22, 2006 at 11:35:34AM -0700, Dave Jones wrote:
>
> (2.6.17rc4-git9)
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> on my dual-core notebook gets me this:
>
Ok, i just tried on my Centrino core duo, and the same online/offline
works just fine for me on git-10. I havent tried git-9 though... could you
give git10 a try?
ashok
^ permalink raw reply
* Re: 2.6.17-rc4 md lock held at task exit
From: Keith Owens @ 2006-05-23 5:56 UTC (permalink / raw)
To: Neil Brown; +Cc: mingo, linux-kernel
In-Reply-To: <17508.13583.730399.209905@cse.unsw.edu.au>
Neil Brown (on Fri, 12 May 2006 17:11:11 +1000) wrote:
>On Friday May 12, kaos@ocs.com.au wrote:
>> Doing poweroff on 2.6.17-rc4 i386, SMP
>>
>> BUG halt/4781, lock held at task exit time!
>> [f7001b34] {mddev_find}
>> .. held by: halt: 4781 [f7cd4030, 118]
>> ... acquired at: md_notify_reboot+0x3a/0xa9 [md_mod}
>>
>
>I suspect this will fix it.
>Is it repeatable? Can you test?
>
>Thanks,
>NeilBrown
>
>
>Signed-off-by: Neil Brown <neilb@suse.de>
>
>### Diffstat output
> ./drivers/md/md.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff ./drivers/md/md.c~current~ ./drivers/md/md.c
>--- ./drivers/md/md.c~current~ 2006-05-12 16:00:03.000000000 +1000
>+++ ./drivers/md/md.c 2006-05-12 17:10:16.000000000 +1000
>@@ -5171,8 +5171,10 @@ static int md_notify_reboot(struct notif
> printk(KERN_INFO "md: stopping all md devices.\n");
>
> ITERATE_MDDEV(mddev,tmp)
>- if (mddev_trylock(mddev))
>+ if (mddev_trylock(mddev)) {
> do_md_stop (mddev, 1);
>+ mddev_unlock(mddev);
>+ }
> /*
> * certain more exotic SCSI devices are known to be
> * volatile wrt too early system reboots. While the
Finally got some time to test this. The problem was reproducable and
the patch fixed it.
Acked-by: Keith Owens <kaos@ocs.com.au>
^ permalink raw reply
* Re: cpu hotplug sleeping from invalid context
From: Ashok Raj @ 2006-05-23 5:42 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel, jacob.shin, akpm
In-Reply-To: <20060522183534.GA8920@redhat.com>
On Mon, May 22, 2006 at 11:35:34AM -0700, Dave Jones wrote:
>
> (2.6.17rc4-git9)
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> on my dual-core notebook gets me this:
>
I was just purging my inbox this morning, and saw a similar report from
Jacob Shin in the x86-64 discuss list. When i checked with him, he replied
that this is now resolved. I didnt ask what it was... Jacob could you
send a pointer to the fix?
Cheers,
ashok
^ permalink raw reply
* Re: [PATCH (try #3)] mm: avoid unnecessary OOM kills
From: Nick Piggin @ 2006-05-23 5:39 UTC (permalink / raw)
To: Dave Peterson; +Cc: linux-kernel, akpm, pj, ak, linux-mm, garlick, mgrondona
In-Reply-To: <200605230032.k4N0WCIU023760@calaveras.llnl.gov>
Dave Peterson wrote:
> Below is a 2.6.17-rc4-mm3 patch that fixes a problem where the OOM killer was
> unnecessarily killing system daemons in addition to memory-hogging user
> processes. The patch fixes things so that the following assertion is
> satisfied:
>
> If a failed attempt to allocate memory triggers the OOM killer, then the
> failed attempt must have occurred _after_ any process previously shot by
> the OOM killer has cleaned out its mm_struct.
>
> Thus we avoid situations where concurrent invocations of the OOM killer cause
> more processes to be shot than necessary to resolve the OOM condition.
Does this fix observed problems on real (or fake) workloads? Can we have
some more information about that?
I still don't quite understand why all this mechanism is needed. Suppose
that we single-thread the oom kill path (which isn't unreasonable, unless
you need really good OOM throughput :P), isn't it enough to find that any
process has TIF_MEMDIE set in order to know that an OOM kill is in progress?
down(&oom_sem);
for each process {
if TIF_MEMDIE
goto oom_in_progress;
else
calculate badness;
}
up(&oom_sem);
I have one other comment, below
> +/* If an OOM kill is not already in progress, try once more to allocate
> + * memory. If allocation fails this time, invoke the OOM killer.
> + */
> +static struct page * oom_alloc(gfp_t gfp_mask, unsigned int order,
> + struct zonelist *zonelist)
> +{
> + static DECLARE_MUTEX(sem);
> + struct page *page;
> +
> + down(&sem);
> +
> + /* Prevent parallel OOM kill operations. This fixes a problem where
> + * the OOM killer was observed shooting system daemons in addition to
> + * memory-hogging user processes.
> + */
> + if (oom_kill_active()) {
> + up(&sem);
> + goto out_sleep;
> + }
> +
> + /* If we get here, we _know_ that any previous OOM killer victim has
> + * cleaned out its mm_struct. Therefore we should pick a victim to
> + * shoot if this allocation fails.
> + */
> + page = get_page_from_freelist(gfp_mask | __GFP_HARDWALL, order,
> + zonelist, ALLOC_WMARK_HIGH | ALLOC_CPUSET);
> +
> + if (page) {
> + up(&sem);
> + return page;
> + }
> +
> + oom_kill_start();
> + up(&sem);
> +
> + /* Try to shoot a process. Call oom_kill_finish() only if the OOM
> + * killer did not shoot anything. If the OOM killer shot something,
> + * mmput() will call oom_kill_finish() once the mm_users count of the
> + * victim's mm_struct has reached 0 and the mm_struct has been cleaned
> + * out.
> + */
> + if (out_of_memory(zonelist, gfp_mask, order))
> + oom_kill_finish(); /* cancel OOM kill */
> +
> +out_sleep:
> + /* Did we get shot by the OOM killer? If not, sleep for a while to
> + * avoid burning lots of CPU cycles looping in the memory allocator.
> + * If the OOM killer shot a process, this gives the victim a good
> + * chance to die before we retry allocation.
> + */
> + if (!test_thread_flag(TIF_MEMDIE))
> + schedule_timeout_uninterruptible(1);
> +
> + return NULL;
> +}
Is all this really required? Shouldn't you just have in place the
mechanism to prevent concurrent OOM killings in the OOM code, and
so the page allocator doesn't have to bother with it at all (ie.
it can just call into the OOM killer, which may or may not actually
kill anything).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: OpenGL-based framebuffer concepts
From: D. Hazelton @ 2006-05-23 0:48 UTC (permalink / raw)
To: Kyle Moffett
Cc: Manu Abraham, linux cbon, Helge Hafting, Valdis.Kletnieks,
linux-kernel
In-Reply-To: <A78F7AE7-C3C2-43DA-9F17-D196CCA7632A@mac.com>
On Tuesday 23 May 2006 05:08, Kyle Moffett wrote:
> Tentatively going with the assumption put forth by Jon Smirl in his
> future-of-linux-graphics document and the open-graphics-project group
> that 3d rendering is an absolutely essential part of any next-
> generation graphics system, I'd be interested in ideas on a new or
> modified /dev/fbX device that offers native OpenGL rendering
> support. Someone once mentioned OpenGL ES as a possibility as it
> provides extensions for multiple-process windowing environments.
> Other requirements would obviously be the ability to allow client
> programs to allocate and share out chunks of graphics memory to other
> clients (later used as textures for compositing), support for
> multiple graphics cards with different hardware renderers over
> different busses, using DMA to transfer data between cards as
> necessary (and user-configurable policy about how to divide use of
> the cards), support for single or multiple framebuffers per GPU, as
> well as an arbitrary number of hardware and software viewports per
> framebuffer. There would also need to be a way for userspace to trap
> and emulate or ignore unsupported OpenGL commands. The kernel would
> need some rudimentary understanding of OpenGL to be able to handle
> buggy GPUs and prevent them from hanging the PCI bus (some GPUs can
> do that if sent invalid commands), but you obviously wouldn't want a
> full software renderer in the kernel. The system should also support
> transmitting OpenGL textures, commands, and other data asynchronously
> over a TCP socket, though doing it locally via mmap would be far more
> efficient. I'm probably missing other necessary generics, but that
> should provide a good discussion starter.
Not that I can see, but the network connectivity bit should probably not be
targeted in the first set of patches. IMHO, the best way to handle this would
be to start merging the DRI drivers into the Framebuffer drivers. This would
then provide some of the infrastructure needed to bring an accelerated
graphics framework into the realm of possibility just in userspace.
In other words - like with everything, the kernel only needs to provide a very
basic set of tools. Provide the kernel with the capacity to handle the
accelerated aspects of video cards seemlessly with the framebuffer driver and
the "Mesa Solo" project would be more than half complete.
By implementing a framework where userspace doesn't have to know - or care -
about the hardware, which, IMNSHO, is the way things should be, then
userspace applications can take advantage of such a system and be even more
stable.
> The necessary kernel support would include a graphics-memory
> allocator, resource management, GPU-time allocation, etc, as well as
> support for an overlaid kernel console. Ideally an improved graphics
> driver like that would be able to dump panics directly to the screen
> composited on top of whatever graphics are being displayed, so you'd
> get panics even while running X. If that kind of support was
> available in-kernel, fixing X to not need root would be far simpler,
> plus you could also write replacement X-like tools without half the
> effort. Given that sort of support, a rootless xserver would be a
> fairly trivial wrapper over whatever underlying implementation there
> was.
Here you outline what is needed, and strangely I find myself thinking that a
lot of this code has already been written. The DRI/DRM system provides a
method for userspace to directly access the acceleration features of graphics
cards. Would it not be possible, then, to take the DRI system, merge it with
the framebuffer system in some manner, and provide a single interface to
userspace?
Even now I know that most applications that directly access the framebuffer
and make use of it have special drivers for the various cards that have
framebuffer drivers in Linux. These might be because of the various
colorspace conventions - like the BGRA (IIRC) of the Radeons - but even that
could be better handled either via a sysfs file or by an ioctl in the
drivers.
But if the Framebuffer system got a makeover, perhaps implementing the
information side as sysfs files and the actual control side as ioctls...
One thing that I've been thinking about is that there is some need for DMA to
and from the card. This would probably best be done by the current S/G DMA
system, as it's a well known and very stable part of the kernel that is
(IIRC) exposed to userspace.
As for allowing direct access to the GPU, about all I can think of is
providing an IOCTL that gives you a pointer to a buffer that you can write
the information to, although a better solution would be to provide a single
IOCTL that takes a userspace buffer and transfers it directly to the GPU.
Neither option seems good to me, since both would require userspace to know
which card it's talking to. So, my only real suggestion is to add another
library to the kernel - one that can translate a user request into the proper
GPU commands and hide all the machinery from the end-user.
DRH
(Note: I do not like any of the GPU access options I mentioned. The first two
because they require userspace knowing which hardware it's talking to when I,
personally, feel that userspace should have no need to know that sort of
information. The last one because it requires adding a complex interpreter to
the kernel, and that screams to me of "bloat".)
^ permalink raw reply
* Re: 2.6.17-rc2+ regression -- audio skipping
From: Peter Williams @ 2006-05-23 5:22 UTC (permalink / raw)
To: Peter Williams
Cc: Mike Galbraith, Con Kolivas, Rene Herman, Lee Revell,
Linux Kernel, Linus Torvalds, Ingo Molnar
In-Reply-To: <44715B5F.6060205@bigpond.net.au>
Peter Williams wrote:
> Mike Galbraith wrote:
>> On Mon, 2006-05-22 at 15:38 +1000, Peter Williams wrote:
>>
>>> In my schedulers I generalize background to "soft cpu rate caps" with
>>> a cap of zero being the same as background. I have patches to add
>>> both soft and hard cpu rate caps to the standard scheduler but I'm
>>> sitting on them until things settle down a bit.
>>
>> I look forward to seeing them. Any chance of a preview?
>>
>
> I'll post them as a "request for comment" tomorrow. I'm still undecided
> about the best user space interface for using them. At the moment, I
> have mechanisms to set them via /proc which is very handy for testing
> but not necessarily the best interface for general use. Other options
> are via rlimits or a syscall.
There'll be a delay in this posting as I've discovered uses of MAX_PRIO
(in 2.7.17-rc4-mm3) that would be broken by my current patches. I'll
fix that problem and hopefully post the patches in the near future.
Sorry
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* OpenGL-based framebuffer concepts
From: Kyle Moffett @ 2006-05-23 5:08 UTC (permalink / raw)
To: Manu Abraham; +Cc: linux cbon, Helge Hafting, Valdis.Kletnieks, linux-kernel
In-Reply-To: <44700ACC.8070207@gmail.com>
Tentatively going with the assumption put forth by Jon Smirl in his
future-of-linux-graphics document and the open-graphics-project group
that 3d rendering is an absolutely essential part of any next-
generation graphics system, I'd be interested in ideas on a new or
modified /dev/fbX device that offers native OpenGL rendering
support. Someone once mentioned OpenGL ES as a possibility as it
provides extensions for multiple-process windowing environments.
Other requirements would obviously be the ability to allow client
programs to allocate and share out chunks of graphics memory to other
clients (later used as textures for compositing), support for
multiple graphics cards with different hardware renderers over
different busses, using DMA to transfer data between cards as
necessary (and user-configurable policy about how to divide use of
the cards), support for single or multiple framebuffers per GPU, as
well as an arbitrary number of hardware and software viewports per
framebuffer. There would also need to be a way for userspace to trap
and emulate or ignore unsupported OpenGL commands. The kernel would
need some rudimentary understanding of OpenGL to be able to handle
buggy GPUs and prevent them from hanging the PCI bus (some GPUs can
do that if sent invalid commands), but you obviously wouldn't want a
full software renderer in the kernel. The system should also support
transmitting OpenGL textures, commands, and other data asynchronously
over a TCP socket, though doing it locally via mmap would be far more
efficient. I'm probably missing other necessary generics, but that
should provide a good discussion starter.
The necessary kernel support would include a graphics-memory
allocator, resource management, GPU-time allocation, etc, as well as
support for an overlaid kernel console. Ideally an improved graphics
driver like that would be able to dump panics directly to the screen
composited on top of whatever graphics are being displayed, so you'd
get panics even while running X. If that kind of support was
available in-kernel, fixing X to not need root would be far simpler,
plus you could also write replacement X-like tools without half the
effort. Given that sort of support, a rootless xserver would be a
fairly trivial wrapper over whatever underlying implementation there
was.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: NMI problems with Dell SMP Xeons
From: Keith Owens @ 2006-05-23 5:03 UTC (permalink / raw)
To: linux-kernel; +Cc: ak
In-Reply-To: <12475.1148288884@kao2.melbourne.sgi.com>
Keith Owens (on Mon, 22 May 2006 19:08:04 +1000) wrote:
>Summary: sending an IPI as NMI will reboot a Dell SMP Xeon box. This
> looks like a problem with setting up the I/O APICs.
Some more data points, which make this problem even less
understandable. My previous mail described an i386 build, so I tried
an x86_64 kernel on two boxes that support 64 bit. Both of them used
flat APIC mode.
Intel M/B, CONFIG_ACPI=y. Sending IPI 2 without APIC_DM_NMI is
unexpectedly delivered as an NMI, and gets the 'Dazed and confused
message'. Contrast this with an i386 kernel with CONFIG_ACPI=y on the
same box, where IPI 2 without APIC_DM_NMI is not delivered as NMI,
instead it gets APIC errors.
Dell SC1425 M/B, CONFIG_ACPI=y. Sending IPI 2 without APIC_DM_NMI is
not delivered at all, but there are no APIC errors. Contrast this with
an i386 kernel with CONFIG_ACPI=y on the same box, where IPI 2 without
APIC_DM_NMI is also not delivered, but it gets APIC errors.
Dell SC1425 M/B, CONFIG_ACPI=y. Sending IPI 2 with APIC_DM_NMI is
delivered as NMI, but it does not get the 'Dazed and confused' message.
Contrast this with an i386 kernel with CONFIG_ACPI=y on the same box,
where IPI 2 with APIC_DM_NMI is also delivered as NMI, but with the
'Dazed and confused' message.
Dell SC1425 M/B, CONFIG_ACPI=n. Sending IPI 2 without APIC_DM_NMI
causes an instant reset. Contrast this with an i386 kernel with
CONFIG_ACPI=n on the same box, which got APIC errors but no reset,
unless APIC_DM_NMI was set.
i386 vs. x86_64 differences. Intel M/B vs. Dell M/B differences.
Colour me confused.
Stripped x86_64 .config.
X86_64=y
64BIT=y
X86=y
SEMAPHORE_SLEEPERS=y
MMU=y
RWSEM_GENERIC_SPINLOCK=y
GENERIC_HWEIGHT=y
GENERIC_CALIBRATE_DELAY=y
X86_CMPXCHG=y
EARLY_PRINTK=y
GENERIC_ISA_DMA=y
GENERIC_IOMAP=y
ARCH_MAY_HAVE_PC_FDC=y
DMI=y
EXPERIMENTAL=y
LOCK_KERNEL=y
INIT_ENV_ARG_LIMIT=32
LOCALVERSION="-kaos"
SWAP=y
SYSVIPC=y
SYSCTL=y
RELAY=y
INITRAMFS_SOURCE=""
UID16=y
VM86=y
CC_OPTIMIZE_FOR_SIZE=y
KALLSYMS=y
KALLSYMS_ALL=y
HOTPLUG=y
PRINTK=y
BUG=y
ELF_CORE=y
BASE_FULL=y
FUTEX=y
EPOLL=y
SHMEM=y
SLAB=y
BASE_SMALL=0
MODULES=y
MODULE_UNLOAD=y
MODULE_FORCE_UNLOAD=y
STOP_MACHINE=y
LBD=y
IOSCHED_NOOP=y
DEFAULT_NOOP=y
DEFAULT_IOSCHED="noop"
X86_PC=y
GENERIC_CPU=y
X86_L1_CACHE_BYTES=128
X86_L1_CACHE_SHIFT=7
X86_INTERNODE_CACHE_BYTES=128
X86_TSC=y
X86_GOOD_APIC=y
X86_MSR=y
X86_CPUID=y
X86_HT=y
X86_IO_APIC=y
X86_LOCAL_APIC=y
MTRR=y
SMP=y
SCHED_SMT=y
SCHED_MC=y
PREEMPT=y
PREEMPT_BKL=y
ARCH_SPARSEMEM_ENABLE=y
ARCH_FLATMEM_ENABLE=y
SELECT_MEMORY_MODEL=y
FLATMEM_MANUAL=y
FLATMEM=y
FLAT_NODE_MEM_MAP=y
SPLIT_PTLOCK_CPUS=4
NR_CPUS=8
HPET_TIMER=y
GART_IOMMU=y
SWIOTLB=y
X86_MCE=y
X86_MCE_INTEL=y
X86_MCE_AMD=y
PHYSICAL_START=0x200000
SECCOMP=y
HZ_250=y
HZ=250
GENERIC_HARDIRQS=y
GENERIC_IRQ_PROBE=y
ISA_DMA_API=y
GENERIC_PENDING_IRQ=y
PM=y
ACPI=y
ACPI_AC=y
ACPI_BATTERY=y
ACPI_BUTTON=y
ACPI_VIDEO=y
ACPI_FAN=y
ACPI_PROCESSOR=y
ACPI_THERMAL=y
ACPI_BLACKLIST_YEAR=0
ACPI_EC=y
ACPI_POWER=y
ACPI_SYSTEM=y
X86_PM_TIMER=y
PCI=y
PCI_DIRECT=y
PCI_MSI=y
BINFMT_ELF=y
BINFMT_MISC=y
IA32_EMULATION=y
COMPAT=y
SYSVIPC_COMPAT=y
NET=y
PACKET=y
PACKET_MMAP=y
UNIX=y
INET=y
IP_FIB_HASH=y
SYN_COOKIES=y
INET_DIAG=y
INET_TCP_DIAG=y
TCP_CONG_BIC=y
NETFILTER=y
NETFILTER_NETLINK=y
NETFILTER_XTABLES=y
NETFILTER_XT_TARGET_CLASSIFY=y
NETFILTER_XT_TARGET_MARK=y
NETFILTER_XT_TARGET_NFQUEUE=y
NETFILTER_XT_TARGET_NOTRACK=y
NETFILTER_XT_MATCH_COMMENT=y
NETFILTER_XT_MATCH_CONNTRACK=y
NETFILTER_XT_MATCH_DCCP=y
NETFILTER_XT_MATCH_HELPER=y
NETFILTER_XT_MATCH_LENGTH=y
NETFILTER_XT_MATCH_LIMIT=y
NETFILTER_XT_MATCH_MAC=y
NETFILTER_XT_MATCH_MARK=y
NETFILTER_XT_MATCH_PKTTYPE=y
NETFILTER_XT_MATCH_REALM=y
NETFILTER_XT_MATCH_SCTP=y
NETFILTER_XT_MATCH_STATE=y
NETFILTER_XT_MATCH_STRING=y
NETFILTER_XT_MATCH_TCPMSS=y
IP_NF_CONNTRACK=y
IP_NF_CONNTRACK_NETLINK=y
IP_NF_FTP=y
IP_NF_IRC=y
IP_NF_QUEUE=y
IP_NF_IPTABLES=y
IP_NF_MATCH_IPRANGE=y
IP_NF_MATCH_TOS=y
IP_NF_MATCH_RECENT=y
IP_NF_MATCH_ECN=y
IP_NF_MATCH_DSCP=y
IP_NF_MATCH_TTL=y
IP_NF_MATCH_OWNER=y
IP_NF_MATCH_ADDRTYPE=y
IP_NF_MATCH_HASHLIMIT=y
IP_NF_FILTER=y
IP_NF_TARGET_REJECT=y
IP_NF_TARGET_LOG=y
IP_NF_TARGET_ULOG=y
IP_NF_TARGET_TCPMSS=y
IP_NF_NAT=y
IP_NF_NAT_NEEDED=y
IP_NF_TARGET_MASQUERADE=y
IP_NF_TARGET_REDIRECT=y
IP_NF_TARGET_NETMAP=y
IP_NF_TARGET_SAME=y
IP_NF_NAT_SNMP_BASIC=y
IP_NF_NAT_IRC=y
IP_NF_NAT_FTP=y
IP_NF_MANGLE=y
IP_NF_TARGET_TOS=y
IP_NF_TARGET_ECN=y
IP_NF_TARGET_DSCP=y
IP_NF_TARGET_TTL=y
IP_NF_RAW=y
IP_NF_ARPTABLES=y
IP_NF_ARPFILTER=y
IP_NF_ARP_MANGLE=y
NET_CLS_ROUTE=y
STANDALONE=y
PREVENT_FIRMWARE_BUILD=y
PARPORT=y
PARPORT_PC=y
BLK_DEV_FD=y
BLK_DEV_LOOP=y
BLK_DEV_RAM=y
BLK_DEV_RAM_COUNT=16
BLK_DEV_RAM_SIZE=4096
IDE=y
BLK_DEV_IDE=y
BLK_DEV_IDEDISK=y
IDEDISK_MULTI_MODE=y
BLK_DEV_IDECD=y
BLK_DEV_IDESCSI=y
IDE_GENERIC=y
BLK_DEV_IDEPCI=y
IDEPCI_SHARE_IRQ=y
BLK_DEV_GENERIC=y
BLK_DEV_IDEDMA_PCI=y
IDEDMA_PCI_AUTO=y
BLK_DEV_PIIX=y
BLK_DEV_IDEDMA=y
IDEDMA_AUTO=y
SCSI=y
SCSI_PROC_FS=y
BLK_DEV_SD=y
BLK_DEV_SR=y
BLK_DEV_SR_VENDOR=y
CHR_DEV_SG=y
SCSI_CONSTANTS=y
SCSI_LOGGING=y
SCSI_SATA=y
SCSI_ATA_PIIX=y
SCSI_SATA_INTEL_COMBINED=y
MD=y
BLK_DEV_MD=y
MD_LINEAR=y
MD_RAID0=y
MD_RAID1=y
MD_RAID10=y
MD_RAID5=y
MD_RAID6=y
MD_MULTIPATH=y
BLK_DEV_DM=y
DM_CRYPT=y
DM_SNAPSHOT=y
DM_MIRROR=y
DM_ZERO=y
NETDEVICES=y
DUMMY=y
TUN=y
NET_ETHERNET=y
MII=y
NET_PCI=y
E100=y
E1000=y
TIGON3=y
PPP=y
PPP_ASYNC=y
PPP_DEFLATE=y
PPP_BSDCOMP=y
INPUT=y
INPUT_MOUSEDEV=y
INPUT_MOUSEDEV_PSAUX=y
INPUT_MOUSEDEV_SCREEN_X=1024
INPUT_MOUSEDEV_SCREEN_Y=768
INPUT_KEYBOARD=y
KEYBOARD_ATKBD=y
INPUT_MOUSE=y
MOUSE_PS2=y
MOUSE_SERIAL=y
SERIO=y
SERIO_I8042=y
SERIO_SERPORT=y
SERIO_PCIPS2=y
SERIO_LIBPS2=y
VT=y
VT_CONSOLE=y
HW_CONSOLE=y
SERIAL_8250=y
SERIAL_8250_CONSOLE=y
SERIAL_8250_PCI=y
SERIAL_8250_NR_UARTS=4
SERIAL_8250_RUNTIME_UARTS=4
SERIAL_8250_EXTENDED=y
SERIAL_CORE=y
SERIAL_CORE_CONSOLE=y
UNIX98_PTYS=y
LEGACY_PTYS=y
LEGACY_PTY_COUNT=256
PRINTER=y
RTC=y
AGP=y
AGP_AMD64=y
AGP_INTEL=y
HWMON=y
VGA_CONSOLE=y
DUMMY_CONSOLE=y
USB_ARCH_HAS_HCD=y
USB_ARCH_HAS_OHCI=y
USB_ARCH_HAS_EHCI=y
EDAC=y
EDAC_DEBUG=y
EDAC_MM_EDAC=y
EDAC_E752X=y
EDAC_POLL=y
EXT2_FS=y
FS_POSIX_ACL=y
XFS_FS=y
XFS_EXPORT=y
XFS_QUOTA=y
ROMFS_FS=y
INOTIFY=y
QUOTACTL=y
DNOTIFY=y
AUTOFS_FS=y
AUTOFS4_FS=y
FUSE_FS=y
ISO9660_FS=y
JOLIET=y
ZISOFS=y
ZISOFS_FS=y
UDF_FS=y
UDF_NLS=y
FAT_FS=y
MSDOS_FS=y
VFAT_FS=y
FAT_DEFAULT_CODEPAGE=437
FAT_DEFAULT_IOCHARSET="iso8859-1"
NTFS_FS=y
PROC_FS=y
PROC_KCORE=y
SYSFS=y
TMPFS=y
RAMFS=y
EFS_FS=y
HPFS_FS=y
UFS_FS=y
NFS_FS=y
NFS_V3=y
NFS_V4=y
NFSD=y
NFSD_V3=y
NFSD_V4=y
NFSD_TCP=y
LOCKD=y
LOCKD_V4=y
EXPORTFS=y
NFS_COMMON=y
SUNRPC=y
SUNRPC_GSS=y
RPCSEC_GSS_KRB5=y
SMB_FS=y
MSDOS_PARTITION=y
NLS=y
NLS_DEFAULT="iso8859-1"
NLS_CODEPAGE_437=y
NLS_CODEPAGE_850=y
NLS_ISO8859_1=y
NLS_UTF8=y
MAGIC_SYSRQ=y
DEBUG_KERNEL=y
LOG_BUF_SHIFT=16
DEBUG_PREEMPT=y
DEBUG_MUTEXES=y
DEBUG_INFO=y
DEBUG_FS=y
FRAME_POINTER=y
FORCED_INLINING=y
DEBUG_RODATA=y
CRYPTO=y
CRYPTO_MD5=y
CRYPTO_DES=y
CRYPTO_AES_X86_64=y
CRC_CCITT=y
CRC32=y
ZLIB_INFLATE=y
ZLIB_DEFLATE=y
TEXTSEARCH=y
TEXTSEARCH_KMP=y
TEXTSEARCH_BM=y
TEXTSEARCH_FSM=y
^ permalink raw reply
* Re: [stable][patch] x86_64: fix number of ia32 syscalls
From: Andi Kleen @ 2006-05-23 2:50 UTC (permalink / raw)
To: Brian Gerst; +Cc: lkml
In-Reply-To: <447249C5.6060706@didntduck.org>
On Tuesday 23 May 2006 01:31, Brian Gerst wrote:
> Andi Kleen wrote:
> > On Monday 22 May 2006 22:59, Chuck Ebbert wrote:
> >> Recent discussions about whether to print a message about unimplemented
> >> ia32 syscalls on x86_64 have missed the real bug: the number of ia32
> >> syscalls is wrong in 2.6.16. Fixing that kills the message.
> >
> > There is already a slightly different patch for this in the FF tree.
> >
>
> Where is the FF tree?
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/
-Andi
^ permalink raw reply
* Re: AMD 8131 MSI quirk called too late, bus_flags not inherited ?
From: Greg KH @ 2006-05-23 4:19 UTC (permalink / raw)
To: Brice Goglin; +Cc: Michael S. Tsirkin, LKML
In-Reply-To: <447069F7.1010407@myri.com>
On Sun, May 21, 2006 at 03:24:07PM +0200, Brice Goglin wrote:
> Michael S. Tsirkin wrote:
> >> @@ -925,8 +926,9 @@
> >> if (dev->no_msi)
> >> return status;
> >>
> >> - if (dev->bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
> >> - return -EINVAL;
> >> + for (bus = dev->bus; bus; bus = bus->parent)
> >> + if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
> >> + return -EINVAL;
> >>
> >> temp = dev->irq;
> >>
> >
> > It seems we must add this loop to pci_enable_msix as well.
> >
>
> Right, thanks. Greg, what do you think of putting the attached patch in
> 2.6.17 ?
Ok, does everyone agree that this patch fixes the issues for them? I've
had a few other private emails saying that the current code doesn't work
properly and hadn't been able to determine what was happening. Thanks
for these patches.
> By the way, do we need to check dev->no_msi in pci_enable_msix() too ?
Yes, good catch, care to respin the patch and give it a good changelog
entry?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Consoldidate arch/{i386,x86_64}/boot/compressed/misc.c
From: Carl-Daniel Hailfinger @ 2006-05-23 3:09 UTC (permalink / raw)
To: Andi Kleen; +Cc: Linux Kernel Mailing List
In-Reply-To: <200605230219.56068.ak@suse.de>
Andi Kleen wrote:
> On Monday 22 May 2006 21:06, Carl-Daniel Hailfinger wrote:
>> Andi Kleen wrote:
>>
>>>> Would a series of incremental patches to consolidate these two
>>>> subtrees get accepted?
>>>>
>>> Yes.
>>>
>>> I have some plans to change the 64bit boot up though - the uncompression
>>> should already run as 64bit - but that shouldnt' affect these files.
>>>
>> Clean up arch/{i386,x86_64}/boot/compressed/misc.c a bit to reduce their
>> differences. Should have zero effect on code generation.
>
> Applied.
Thanks!
Could you have a look at the remaining differences and tell me what else
can be nuked?
* For the CONFIG_X86_NUMAQ stuff there were some patches flying around,
but it seems they never got applied.
* The hand-coded stack is probably a bootloader thing, but I don't yet
understand why it's only in i386.
* The "uncompressing" messages differ. Any reason for that?
* The list of includes differs. Probably related to NUMAQ and stack.
* decompress_kernel is asmlinkage only on i386.
--- linux-2.6.17-rc4/arch/i386/boot/compressed/misc.c 2006-05-22 20:56:09.000000000 +0200
+++ linux-2.6.17-rc4/arch/x86_64/boot/compressed/misc.c 2006-05-22 20:56:30.000000000 +0200
@@ -9,8 +9,6 @@
* High loaded stuff by Hans Lermen & Werner Almesberger, Feb. 1996
*/
-#include <linux/linkage.h>
-#include <linux/vmalloc.h>
#include <linux/screen_info.h>
#include <asm/io.h>
#include <asm/page.h>
@@ -116,10 +114,6 @@
static int vidport;
static int lines, cols;
-#ifdef CONFIG_X86_NUMAQ
-static void * xquad_portio = NULL;
-#endif
-
#include "../../../../lib/inflate.c"
static void *malloc(int size)
@@ -287,15 +281,6 @@
while(1); /* Halt */
}
-#define STACK_SIZE (4096)
-
-long user_stack [STACK_SIZE];
-
-struct {
- long * a;
- short b;
- } stack_start = { & user_stack [STACK_SIZE] , __BOOT_DS };
-
static void setup_normal_output_buffer(void)
{
#ifdef STANDARD_MEMORY_BIOS_CALL
@@ -346,7 +331,7 @@
}
}
-asmlinkage int decompress_kernel(struct moveparams *mv, void *rmode)
+int decompress_kernel(struct moveparams *mv, void *rmode)
{
real_mode = rmode;
@@ -365,9 +350,9 @@
else setup_output_buffer_if_we_run_high(mv);
makecrc();
- putstr("Uncompressing Linux... ");
+ putstr(".\nDecompressing Linux...");
gunzip();
- putstr("Ok, booting the kernel.\n");
+ putstr("done.\nBooting the kernel.\n");
if (high_loaded) close_output_buffer_if_we_run_high(mv);
return high_loaded;
}
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* I'm here, Refresh later
From: Julia Abernathy5 @ 2006-05-23 3:58 UTC (permalink / raw)
To: linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 401 bytes --]
Dear Home-0wner,
You have been pre-approved for a $401,500 Home Loan at a 3.25% Fixed Rate.
This 0ffer is being extended to you unconditionally and your cred1t is in
no way a factor.
To take Advantage of this Lim1ted T1me 0pportunity all
we ask is that you visit 0ur Website and complete
the 1 minute post Approval Form.
http://joerate.com/luck/
Sincerely,
Julia Abernathy
Regional Manager
^ permalink raw reply
* Re: Linux Kernel Source Compression
From: Stefan Smietanowski @ 2006-05-23 2:55 UTC (permalink / raw)
To: Nuri Jawad
Cc: Alistair John Strachan, Jan Engelhardt, H. Peter Anvin,
linux-kernel
In-Reply-To: <Pine.LNX.4.64.0605230407320.25860@pc>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
Nuri Jawad wrote:
> Hi,
> just wanted to remark that I never liked that bzip was replaced by bzip2
> (were there license issues?) since bzip's compression was/is often
> stronger:
bzip was (possibly) infringing a patent so a method bzip used was
removed and subsequently bzip2 was created.
http://lists.debian.org/debian-devel/1997/12/msg00778.html
// Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply
* Re: cpusets: only wakeup kswapd for zones in the current cpuset
From: Christoph Lameter @ 2006-05-23 2:28 UTC (permalink / raw)
To: Paul Jackson; +Cc: linux-kernel, chrisw
In-Reply-To: <20060522192248.b114fea3.pj@sgi.com>
On Mon, 22 May 2006, Paul Jackson wrote:
> > None if that is the case.
>
> Take a look at wakeup_kswapd() for yourself ;).
> No need to speculate.
Yes there is a check in wakeup_kswapd(). Remove the patch. It was quite a
while ago. I think I saw various functions in __alloc_pages() only being
called after checking cpusets. wakeup_kswapd() did not have that check
which was strange.
^ permalink raw reply
* Re: NMI problems with Dell SMP Xeons
From: Keith Owens @ 2006-05-23 2:21 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
In-Reply-To: <5767.1148349730@kao2.melbourne.sgi.com>
Keith Owens (on Tue, 23 May 2006 12:02:10 +1000) wrote:
>Andi Kleen (on Tue, 23 May 2006 03:55:48 +0200) wrote:
>>nd add special cases just to get an NMI send with different vector.
>>>
>>> I have never disagreed that all NMIs will end up on the NMI vector (2).
>>
>>The problem was that KDB had an own handler for its debug vector,
>>although that was only ever called as NMI.
>
>You are confusing KDB_ENTER (instruction code 'int 0x81') with
>KDB_VECTOR (IPI). KDB_ENTER needs its own int handler which is not an
>NMI, KDB_VECTOR does not need (and does not have) its own handler, it
>is handled by the NMI vector.
Or you might be thinking of kdb-v0.6-2.2.13 and earlier, which did have
a spurious handler for KDB_VECTOR. But that was fixed in
kdb-v1.0-2.3.29, back in January 2000. You are not going to hold that
against me are you, especially since I was not maintaining KDB then?
^ permalink raw reply
* Re: cpusets: only wakeup kswapd for zones in the current cpuset
From: Paul Jackson @ 2006-05-23 2:22 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-kernel, chrisw
In-Reply-To: <Pine.LNX.4.64.0605221858250.7165@schroedinger.engr.sgi.com>
> None if that is the case.
Take a look at wakeup_kswapd() for yourself ;).
No need to speculate.
Do you recall why you posted this patch? The
wording made it sound like you had hit some
problem with waking up kswapd for all the nodes.
If you really saw that, then it would seem that
we still have a problem, that is now lacking a fix.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: Linux Kernel Source Compression
From: Nuri Jawad @ 2006-05-23 2:16 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: Jan Engelhardt, H. Peter Anvin, linux-kernel
In-Reply-To: <200605222200.18351.s0348365@sms.ed.ac.uk>
Hi,
just wanted to remark that I never liked that bzip was replaced by bzip2
(were there license issues?) since bzip's compression was/is often
stronger:
39843104 Mar 28 09:33 linux-2.6.15.7.tar.bz2
39423739 Mar 28 09:33 linux-2.6.15.7.tar.bz
Not a big difference in this case but still a step back. I for once am
keeping my bzip binary.. does anyone know where the source can still be
found?
Regards, Nuri
^ permalink raw reply
* Re: NMI problems with Dell SMP Xeons
From: Keith Owens @ 2006-05-23 2:02 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
In-Reply-To: <200605230355.48399.ak@suse.de>
Andi Kleen (on Tue, 23 May 2006 03:55:48 +0200) wrote:
>nd add special cases just to get an NMI send with different vector.
>>
>> I have never disagreed that all NMIs will end up on the NMI vector (2).
>
>The problem was that KDB had an own handler for its debug vector,
>although that was only ever called as NMI.
You are confusing KDB_ENTER (instruction code 'int 0x81') with
KDB_VECTOR (IPI). KDB_ENTER needs its own int handler which is not an
NMI, KDB_VECTOR does not need (and does not have) its own handler, it
is handled by the NMI vector.
^ permalink raw reply
* Re: [IDEA] Poor man's UPS
From: Martin J. Bligh @ 2006-05-23 2:02 UTC (permalink / raw)
To: Avi Kivity
Cc: Christian Trefzer, Matthias Schniedermeyer, Alan Cox, Jan Knutar,
Pau Garcia i Quiles, linux-kernel
In-Reply-To: <447214EF.50803@argo.co.il>
>> Exactly, and since I cannot afford to buy one I'd have to build it
>> myself using mainly car batteries. The most complex part would be to
>> charge the batteries in a way that won't kill them over time. Building
>> such stuff into the PSU after the secondary coil and AC/DC converter
>> would save the double-conversion loss, therefore making this ideal for a
>> single machine. But I'm still brainstorming, lacking both money and
>> time.
>
> Led/acid batteries are dangerous. Don't use them unless you know exactly
> what you are doing.
Buy an intelligent charger for an RV. They're designed to do pretty much
exactly that (deep cycle marine batteries, probably).
M.
^ permalink raw reply
* Re: cpusets: only wakeup kswapd for zones in the current cpuset
From: Christoph Lameter @ 2006-05-23 1:59 UTC (permalink / raw)
To: Paul Jackson; +Cc: Christoph Lameter, linux-kernel, Chris Wright
In-Reply-To: <20060522182356.fbea4aec.pj@sgi.com>
On Mon, 22 May 2006, Paul Jackson wrote:
> Three months ago, Christoph wrote:
> > If we get under some memory pressure in a cpuset (we only scan zones
> > that are in the cpuset for memory) then kswapd is woken
> > up for all zones. This patch only wakes up kswapd in zones that are
> > part of the current cpuset.
> >
> > Signed-off-by: Christoph Lameter <clameter@sgi.com>
> >
> > Index: linux-2.6.16-rc2/mm/page_alloc.c
> > ===================================================================
> > --- linux-2.6.16-rc2.orig/mm/page_alloc.c 2006-02-02 22:03:08.000000000 -0800
> > +++ linux-2.6.16-rc2/mm/page_alloc.c 2006-02-08 00:05:09.000000000 -0800
> > @@ -923,7 +923,8 @@ restart:
> > goto got_pg;
> >
> > do {
> > - wakeup_kswapd(*z, order);
> > + if (cpuset_zone_allowed(*z, gfp_mask))
> > + wakeup_kswapd(*z, order);
> > } while (*(++z));
> >
> > /*
> >
>
> Christoph,
>
> Does this patch serve any use? Chris Wright just noticed (in private
> email) that wakeup_kswapd() already contains a check for cpuset
> confinement, so it would seem the above added check is superfluous.
None if that is the case.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox