* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Davide Libenzi @ 2002-01-15 1:58 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Ingo Molnar, lkml, Dave Jones
In-Reply-To: <Pine.LNX.4.40.0201141748570.1233-100000@blue1.dev.mcafeelabs.com>
On Mon, 14 Jan 2002, Davide Libenzi wrote:
On Mon, 14 Jan 2002, Ed Tomlinson wrote:
> On January 13, 2002 10:45 pm, Davide Libenzi wrote:
> > On Sun, 13 Jan 2002, Ed Tomlinson wrote:
> > > With pre3+H7, kernel compiles still take 40% longer with a setiathome
> > > process running at nice +19. This is _not_ the case with the old
> > > scheduler.
> >
> > Did you try to set MIN_TIMESLICE to 10 ( sched.h ) ?make bzImage with setiathome running nice +19
>
> This makes things a worst - note the decreased cpu utilizaton...
>
> make bzImage 424.33s user 32.21s system 48% cpu 15:48.69 total
>
> What is this telling us?
I got it, the new scheduler assign time slices depending on priority.
Maybe Ingo it's better to assign them depending on nice since we already
have different time slices based on priority ( interactive handling in
expire_task() ).
- Davide
^ permalink raw reply
* Re: [linux-lvm] (no subject)
From: Stefan Huber @ 2002-01-15 1:51 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <wvzo3g3w01.fsf@freeze.oslo.dnmi.no>
Hello Adrian
yes, you`ve right!
i downloaded last evening a newer verision of lvm 1.0 ....
i will try to install it at this evening....
thanxs
steve
Adrian Phillips wrote:
> >>>>> "Stefan" == Stefan Huber <stefan.huber@eds.com> writes:
>
> Stefan> Hello Adrian i`m using LVM Version 0.8e
>
> Ouch, very old. Check out the LVM web page and download the latest
> tools (1.0.1)
>
> Sincerely,
>
> Adrian
>
> --
> Your mouse has moved.
> Windows NT must be restarted for the change to take effect.
> Reboot now? [OK]
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
____________________________________________________________________
Stefan Huber
EDS Information Business GmbH
Storage Management
Telefon +41(0)52 674 86 56
Fax +41(0)52 674 86 94
e-mail stefan.huber@eds.com
^ permalink raw reply
* Defining new section for bus driver init
From: Patrick Mochel @ 2002-01-15 1:47 UTC (permalink / raw)
To: linux-kernel
Currently, in init/main.c, static calls are made to some device
subsystems, like this:
#ifdef CONFIG_PCI
pci_init();
#endif
By careful examination and a bit of mediatating, I have inferred a few
things about those calls.
They initialize the "root" buses in the system - the buses that hang right
off of the equivalent of the host controller (i.e. north bridge) on $arch.
They are statically called in do_basic_setup() because if they used
__initcall(), it would hard, if not impossible, to guarantee that they are
called before anything else.
The collection of them in init/main.c is ugly, and the model doesn't scale
well.
Attached is a patch that creates a new section for device subsystem init
calls. With it, the root bus init calls are handled just like init calls
- the section consists of a table of function pointers.
device_driver_init() iterates over that table and calls each one.
(device_driver_init() currently happens just before that pci_init() call
above).
What do people think about the concept? I am more than willing to port the
other calls to it, as well add the vmlinux.lds entries (though both are
trivial). I don't have any other hardware to test on, though, besides an
x86 PCI-based system.
I will warn that the name is kinda clumsy, but it's the best that I could
come up with (I wasted my creativity for the day on thinking about
Penelope). I used "subsystem" because I have alterior motives.
In order for a driver to be loaded, there needs to be drivers for the bus
on which it resides loaded, and drivers for the device class to which it
belongs (disk, network, etc) loaded.
Buses that are not currently "root" buses have initcall init calls. All
device classes do, too. And the device-specific drivers are in there, too.
Bus and class drivers need to be loaded before device drivers, and they
do not depend on each other, so it seems that they can be grouped
together in a section and called (like below). Right?
-pat
diff -Nur linux-2.5.1.orig/arch/i386/vmlinux.lds linux-2.5.1/arch/i386/vmlinux.lds
--- linux-2.5.1.orig/arch/i386/vmlinux.lds Mon Jul 2 14:40:14 2001
+++ linux-2.5.1/arch/i386/vmlinux.lds Mon Jan 14 16:50:12 2002
@@ -50,6 +50,11 @@
__initcall_start = .;
.initcall.init : { *(.initcall.init) }
__initcall_end = .;
+
+ __devsubsys_start = .;
+ .devsubsys.init : { *(.devsubsys.init) }
+ __devsubsys_end = .;
+
. = ALIGN(4096);
__init_end = .;
diff -Nur linux-2.5.1.orig/drivers/pci/pci.c linux-2.5.1/drivers/pci/pci.c
--- linux-2.5.1.orig/drivers/pci/pci.c Tue Nov 20 21:53:29 2001
+++ linux-2.5.1/drivers/pci/pci.c Mon Jan 14 16:57:44 2002
@@ -1929,7 +1929,7 @@
}
-void __devinit pci_init(void)
+int __devinit pci_init(void)
{
struct pci_dev *dev;
@@ -1942,6 +1942,7 @@
#ifdef CONFIG_PM
pm_register(PM_PCI_DEV, 0, pci_pm_callback);
#endif
+ return 0;
}
static int __devinit pci_setup(char *str)
@@ -1958,6 +1959,8 @@
}
return 1;
}
+
+__devsubsys_init(pci_init);
__setup("pci=", pci_setup);
diff -Nur linux-2.5.1.orig/include/linux/init.h linux-2.5.1/include/linux/init.h
--- linux-2.5.1.orig/include/linux/init.h Fri Dec 21 16:05:57 2001
+++ linux-2.5.1/include/linux/init.h Mon Jan 14 16:54:08 2002
@@ -55,6 +55,12 @@
#define __exitcall(fn) \
static exitcall_t __exitcall_##fn __exit_call = fn
+/* device subsystem initialization */
+extern initcall_t __devsubsys_start, __devsubsys_end;
+
+#define __devsubsys_init(fn) \
+static initcall_t __devsubsys_##fn __devsubsys_call = fn;
+
/*
* Used for kernel command line parameter setup
*/
@@ -82,6 +88,7 @@
#define __initsetup __attribute__ ((unused,__section__ (".setup.init")))
#define __init_call __attribute__ ((unused,__section__ (".initcall.init")))
#define __exit_call __attribute__ ((unused,__section__ (".exitcall.exit")))
+#define __devsubsys_call __attribute__ ((unused,__section__ (".devsubsys.init")))
/* For assembly routines */
#define __INIT .section ".text.init","ax"
diff -Nur linux-2.5.1.orig/include/linux/pci.h linux-2.5.1/include/linux/pci.h
--- linux-2.5.1.orig/include/linux/pci.h Fri Dec 21 16:06:13 2001
+++ linux-2.5.1/include/linux/pci.h Mon Jan 14 17:32:42 2002
@@ -525,7 +525,7 @@
/* Generic PCI functions used internally */
-void pci_init(void);
+int pci_init(void);
int pci_bus_exists(const struct list_head *list, int nr);
struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops, void *sysdata);
struct pci_bus *pci_alloc_primary_bus(int bus);
diff -Nur linux-2.5.1.orig/init/main.c linux-2.5.1/init/main.c
--- linux-2.5.1.orig/init/main.c Wed Jan 9 11:03:06 2002
+++ linux-2.5.1/init/main.c Mon Jan 14 17:35:25 2002
@@ -38,10 +38,6 @@
#include <asm/ccwcache.h>
#endif
-#ifdef CONFIG_PCI
-#include <linux/pci.h>
-#endif
-
#ifdef CONFIG_DIO
#include <linux/dio.h>
#endif
@@ -481,9 +477,6 @@
/* bring up the device tree */
device_driver_init();
-#ifdef CONFIG_PCI
- pci_init();
-#endif
#ifdef CONFIG_SBUS
sbus_init();
#endif
diff -Nur linux-2.5.1.orig/kernel/device.c linux-2.5.1/kernel/device.c
--- linux-2.5.1.orig/kernel/device.c Wed Jan 9 11:03:00 2002
+++ linux-2.5.1/kernel/device.c Mon Jan 14 17:03:46 2002
@@ -890,6 +890,17 @@
return (device_root.dir ? 0 : -EFAULT);
}
+initcall_t __devsubsys_start, __devsubsys_end;
+
+static void device_subsys_init(void)
+{
+ initcall_t * fn = &__devsubsys_start;
+
+ do {
+ (*fn)();
+ } while (++fn < &__devsubsys_end);
+}
+
int __init device_driver_init(void)
{
int error = 0;
@@ -910,6 +921,8 @@
printk(KERN_ERR "%s: device root init failed!\n", __FUNCTION__);
return error;
}
+
+ device_subsys_init();
DBG("DEV: Done Initialising\n");
return error;
^ permalink raw reply
* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Davide Libenzi @ 2002-01-15 1:50 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Ingo Molnar, lkml, Dave Jones
In-Reply-To: <20020115013732.384A6BB346@oscar.casa.dyndns.org>
On Mon, 14 Jan 2002, Ed Tomlinson wrote:
> On January 13, 2002 10:45 pm, Davide Libenzi wrote:
> > On Sun, 13 Jan 2002, Ed Tomlinson wrote:
> > > With pre3+H7, kernel compiles still take 40% longer with a setiathome
> > > process running at nice +19. This is _not_ the case with the old
> > > scheduler.
> >
> > Did you try to set MIN_TIMESLICE to 10 ( sched.h ) ?make bzImage with setiathome running nice +19
>
> This makes things a worst - note the decreased cpu utilizaton...
>
> make bzImage 424.33s user 32.21s system 48% cpu 15:48.69 total
>
> What is this telling us?
Doh !
Did you set this ?
#define MIN_TIMESLICE (10 * HZ / 1000)
- Davide
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Stephan von Krawczynski @ 2002-01-15 1:43 UTC (permalink / raw)
To: Jussi Laako; +Cc: Alan Cox, Andrew Morton, linux-kernel
In-Reply-To: <3C435995.24B8880B@kolumbus.fi>
> Alan Cox wrote:
> >
> > > > In eepro100.c, wait_for_cmd_done() can busywait for one
millisecond
> > > > and is called multiple times under spinlock.
> > >
> > > Did I get that right, as long as spinlocked no sense in
> > > conditional_schedule()
> >
> > No conditional schedule, no pre-emption. You would need to rewrite
that
> > code to do something like try for 100uS then queue a 1 tick timer
to
> > retry asynchronously. That makes the code vastly more complex for
an
> > error case and for some drivers where irq mask is required during
reset
> > waits won't help.
>
> That wait_for_cmd_done() and similar functions in other drivers are
called
> let's say 3 times in interrupt handler or spinlocked routine and 20
times in
> non-interrupts disabled nor spinlocked functions.
>
> Spinlocked reqions are usually protected by spin_lock_irqsave().
Now I have really waited for this one: _usually_.
My servers work usually, except for the days they hit that other
rather unusual part of the code...
> So the code reads
>
> if (!spin_is_locked(sl))
> conditional_schedule();
>
> This doesn't make the whole problem go away, but could make the
situation a
> little bit better for most of the time?
Time to take out these big hats and rename ourself to Gandalf or the
like. What do you expect your server to do, having no problem "most of
the time"? Please read Albert E. Time can be pretty relative to your
personal point of view...
Regards,
Stephan
^ permalink raw reply
* Re: Penelope builds a kernel
From: Tom Rini @ 2002-01-15 1:39 UTC (permalink / raw)
To: Eric S. Raymond, linux-kernel
In-Reply-To: <20020114165909.A20808@thyrsus.com>
On Mon, Jan 14, 2002 at 04:59:09PM -0500, Eric S. Raymond wrote:
[snip]
> She's just heard about a PCMCIA card that has a MEMS array of chemical
> sensors on it. The thing could replace the bulky, balky
> gel-chromatography setup she's using now, and make it unnecessary for
> her to fight other students for bench time. There's even a Linux
> driver for the card (and user-space utilities to talk to it) on one of
> the bio sites she uses -- way too specialized an item for her distro
> to carry, and anyway she doesn't want to wait for the next release.
>
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
[snip]
Wrong. She needs to compile a new module for her kernel. What might be
useful is some automagic tool that will find the vendor-provided kernel
source tree and config (which is usually /boot/config-`uname -r`, but
still findable anyhow) and then compile said module for her, toss it
into the modules dir and maybe even add it to the always-loaded module
list (just incase hotplug doesn't grok it).
With some support from people writing external drivers, you could even
have a file that lists things like which files are needed, a URL and
version info, and store it someplace too.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Eric S. Raymond @ 2002-01-15 1:21 UTC (permalink / raw)
To: Alan Cox; +Cc: arjan, linux-kernel
In-Reply-To: <E16QGVZ-0003Ky-00@the-village.bc.nu>
Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > You miss my point. Sure he's entitled to them. But why should he
> > *have to have them*? They're extra state which, in the presence
> > of a proper autoconfigurator, he doesn't need.
>
> You have it backwards. The _autoconfigurator_ is extra state which in the
> presence of the config he doesn't need
Oh, come on Alan. You can do better than that.
If Melvin loses the autoconfigurator, there's no state he has to reconstruct.
There will be one exactly like it in the next tarball.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
[The disarming of citizens] has a double effect, it palsies the hand
and brutalizes the mind: a habitual disuse of physical forces totally
destroys the moral [force]; and men lose at once the power of
protecting themselves, and of discerning the cause of their
oppression.
-- Joel Barlow, "Advice to the Privileged Orders", 1792-93
^ permalink raw reply
* Re: [linux-lvm] (no subject)
From: Adrian Phillips @ 2002-01-15 1:38 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <3C43DA17.473295EE@eds.com>
>>>>> "Stefan" == Stefan Huber <stefan.huber@eds.com> writes:
Stefan> Hello Adrian i`m using LVM Version 0.8e
Ouch, very old. Check out the LVM web page and download the latest
tools (1.0.1)
Sincerely,
Adrian
--
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now? [OK]
^ permalink raw reply
* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Ed Tomlinson @ 2002-01-15 1:37 UTC (permalink / raw)
To: Davide Libenzi; +Cc: mingo, linux-kernel, Dave Jones
In-Reply-To: <Pine.LNX.4.40.0201131944290.933-100000@blue1.dev.mcafeelabs.com>
On January 13, 2002 10:45 pm, Davide Libenzi wrote:
> On Sun, 13 Jan 2002, Ed Tomlinson wrote:
> > With pre3+H7, kernel compiles still take 40% longer with a setiathome
> > process running at nice +19. This is _not_ the case with the old
> > scheduler.
>
> Did you try to set MIN_TIMESLICE to 10 ( sched.h ) ?make bzImage with setiathome running nice +19
This makes things a worst - note the decreased cpu utilizaton...
make bzImage 424.33s user 32.21s system 48% cpu 15:48.69 total
What is this telling us?
Ed Tomlinson
>>make bzImage 391.11s user 30.85s system 62% cpu 11:17.37 total
>>
>>make bzImage alone
>>
>>make bzImage 397.33s user 32.14s system 92% cpu 7:43.58 total
>>
>>Notice the large difference in run times...
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Stephan von Krawczynski @ 2002-01-15 1:34 UTC (permalink / raw)
To: Jussi Laako; +Cc: Alan Cox, linux-kernel
In-Reply-To: <3C4355AE.5676F0F3@kolumbus.fi>
> Stephan von Krawczynski wrote:
> I also checked the tulip driver (which is the one I use at home) and
didn't
> find need for "fixing" there. I will definitely take a closer look
at that
> driver in future.
Aha, I see, everything as expected...
> WLAN drivers seem to need some hacking, but I'm not very interested
in that
> area. I think WLAN is one big security hole that noone should be
using...
Uhm, I got hot news: internet is insecure.
Come on, this is really silly, every network is a security problem,
not speaking of the guys sitting in front of the screens...
Regards,
Stephan
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: J Sloan @ 2002-01-15 1:31 UTC (permalink / raw)
To: Daniel Phillips
Cc: J Sloan, Robert Love, jogi, Andrew Morton, Ed Sweetman,
Andrea Arcangeli, yodaiken, Alan Cox, nigel, Rob Landley,
linux-kernel
In-Reply-To: <E16Q0wQ-0000ks-00@starship.berlin>
Daniel Phillips wrote:
>On January 13, 2002 08:35 pm, J Sloan wrote:
>
>>The problem here is that when people report
>>that the low latency patch works better for them
>>than the preempt patch, they aren't talking about
>>bebnchmarking the time to compile a kernel, they
>>are talking about interactive feel and smoothness.
>>
>
>Nobody is claiming the low latency patch works better than
>-preempt+lock_break, only that low latency can equal -preempt+lock_break,
>which is a claim I'm skeptical of, but oh well.
>
AFAICT Alan Cox et al are saying that low-latency
gives better latency than -preempt, but that if lock-break
is added to -preempt, the results are basically the same.
IOW lock-break + preempt =~ low-latency as far as the
latency question is concerned.
>>I've no agenda other than wanting to see linux
>>as an attractive option for the multimedia and
>>gaming crowds - and in my experience, the low
>>latency patches simply give a much smoother
>>feel and a more pleasant experience. Kernel
>>compilation time is the farthest thing from my
>>mind when e.g. playing Q3A!
>>
>
>You need to read the thread *way* more closely ;-)
>
Admittedly my observations have been more from
an "end-user" point of view, because at the end
of the day, what I experience while using Linux as
a multimedia/gaming platform is worth more than a
barrel of benchmarks - and while kernel compilation
time is of interest, it is just _one_ benchmark in the
greater scheme of things. (not to mention that that
benchmark result could probably be matched in a
non -preempt kernel via /proc tuning)
>>I'd be happy to check out the preempt patch
>>again and see if anything's changed, if the
>>problem of tux+preempt oopsing has been
>>dealt with -
>>
>
>Right, useful.
>
See my previous reply, or the archives -
Regards,
jjs
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Tom Rini @ 2002-01-15 1:30 UTC (permalink / raw)
To: Justin Carlson; +Cc: esr, linux-kernel
In-Reply-To: <1011040246.19071.42.camel@gs256.sp.cs.cmu.edu>
On Mon, Jan 14, 2002 at 03:30:46PM -0500, Justin Carlson wrote:
> From the other side, how does having the ability to probe local hardware
> hurt? It should be cleanly seperable from the classical build process
> for the purists, and helpful to some (I think) significant portion of
> the userbase, particularly those folks who like to test bleeding edge
> stuff on a variety of hardware. I don't really understand the
> resistance to the idea of someone going out and implementing this.
Right, and this is 95% possible even. Doing PCI stuff is rather easy
(since we've got it all mapped out even). The problem is the 100%
point-click-run goal that Eric has.
The original sticking point was doing ISA (and other buses that are
_not_ autodetect friendly in a safe way).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [linux-lvm] (no subject)
From: Stefan Huber @ 2002-01-15 1:31 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <wvheppkkzg.fsf@freeze.oslo.dnmi.no>
Hello Adrian
i`m using LVM Version 0.8e
greetzz
steve
Adrian Phillips wrote:
> >>>>> "Stefan" == Stefan Huber <stefan.huber@eds.com> writes:
>
> Stefan> hello lvm-list i tried to change my kernel from 2.2.14 to
> Stefan> 2.2.19 now most of them are running very
> Stefan> fine...... but.....
>
> Stefan> if i will start the new kernel there is a error message
> Stefan> like this:
>
> Stefan> vgscan -- wrong i/o protocol version....
>
> Stefan> it seems to be, that there is something wrong with my
> Stefan> lvm-version ? or, isn`t it?
>
> Um, perhaps you need newer version of the lvm progs ? What version do
> you have ?
>
> Sincerely,
>
> Adrian Phillips
>
> --
> Your mouse has moved.
> Windows NT must be restarted for the change to take effect.
> Reboot now? [OK]
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
____________________________________________________________________
Stefan Huber
EDS Information Business GmbH
Storage Management
Telefon +41(0)52 674 86 56
Fax +41(0)52 674 86 94
e-mail stefan.huber@eds.com
^ permalink raw reply
* Re: [RFC] klibc requirements, round 2
From: Oliver Xymoron @ 2002-01-15 1:26 UTC (permalink / raw)
To: Andreas Dilger
Cc: Theodore Tso, Juan Quintela, Greg KH, linux-kernel,
felix-dietlibc, andersen
In-Reply-To: <20020114165849.B26688@lynx.adilger.int>
On Mon, 14 Jan 2002, Andreas Dilger wrote:
> Actually, the whole point of Juan's suggestion was that you _don't_ want
> to fsck a filesystem that is currently mounted. There is always a
> potential problem that fsck will change the on-disk data of the filesystem
> in a way that is not coherent with what the kernel has in-memory, which
> should force a system reboot before continuing (which most initscripts
> don't do). For ext2/ext3 this may be relatively safe (data/metadata don't
> move around much), but reiserfsck cannot (or will not) fsck a mounted
> filesystem at all.
Interesting point. Modulo any existing LVM brokenness, we can do this with
a read-only snapshot and pivot_root afterwards. Alternately, a read-only
/bootsupport or something of the sort which contains *fsck. What we don't
want is initramfs to get big.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
^ permalink raw reply
* RE: MIPS64 status?
From: Matthew Dharm @ 2002-01-15 0:27 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-mips
In-Reply-To: <Pine.LNX.3.96.1020114165623.28388B-100000@wakko.deltatee.com>
Hrm...
Were you actually using 64-bit addresses on the PCI bus?
My guess is that with some creative address mappings, this could be
done. The PCI bus itself would use only 32-bit address, but the CPU
would use a base address offset into the >4G range.
Yeah, I could see how that could get ugly...
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: owner-linux-mips@oss.sgi.com
> [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Jason Gunthorpe
> Sent: Monday, January 14, 2002 4:00 PM
> To: Matthew Dharm
> Cc: linux-mips@oss.sgi.com
> Subject: RE: MIPS64 status?
>
>
>
> On Mon, 14 Jan 2002, Matthew Dharm wrote:
>
> > Does this mean we could map PCI memory/IO addresses above
> 4G and have
> > it work?
>
> Ooh, don't go there :> We looked at that and actually did
> it then backed
> it out.
>
> The PCI spec (particuarly PCI-X) tries to make it possible, but in a
> general system with PCI sockets/etc it is just is not feasible. PCI
> bridges need to be located below 4G, as do the majority of
> devices made.
> There is also a performance hit for having device registers > 4G.
>
> You'd definately need the mips64 kernel to do that, or use
> ugly wired TLB
> entries with normal mips.
>
> Jason
>
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: M.H.VanLeeuwen @ 2002-01-15 1:27 UTC (permalink / raw)
To: m.knoblauch; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <3C430662.71C4F3D8@TeraPort.de>
Martin Knoblauch wrote:
>
> > Re: [2.4.17/18pre] VM and swap - it's really unusable
> >
> >
> > Ken,
> >
> > Attached is an update to my previous vmscan.patch.2.4.17.c
> >
> > Version "d" fixes a BUG due to a race in the old code _and_
> > is much less agressive at cache_shrinkage or conversely more
> > willing to swap out but not as much as the stock kernel.
> >
> > It continues to work well wrt to high vm pressure.
> >
> > Give it a whirl to see if it changes your "-j" symptoms.
> >
> > If you like you can change the one line in the patch
> > from "DEF_PRIORITY" which is "6" to progressively smaller
> > values to "tune" whatever kind of swap_out behaviour you
> > like.
> >
> > Martin
> >
> Martin,
>
> looking at the "d" version, I have one question on the piece that calls
> swap_out:
>
> @@ -521,6 +524,9 @@
> }
> spin_unlock(&pagemap_lru_lock);
>
> + if (max_mapped <= 0 && (nr_pages > 0 || priority <
> DEF_PRIORITY))
> + swap_out(priority, gfp_mask, classzone);
> +
> return nr_pages;
> }
>
> Curious on the conditions where swap_out is actually called, I added a
> printk and found actaully cases where you call swap_out when nr_pages is
> already 0. What sense does that make? I would have thought that
> shrink_cache had done its job in that case.
>
> shrink_cache: 24 page-request, 0 pages-to swap, max_mapped=-1599,
> max_scan=4350, priority=5
> shrink_cache: 24 page-request, 0 pages-to swap, max_mapped=-487,
> max_scan=4052, priority=5
> shrink_cache: 29 page-request, 0 pages-to swap, max_mapped=-1076,
> max_scan=1655, priority=5
> shrink_cache: 2 page-request, 0 pages-to swap, max_mapped=-859,
> max_scan=820, priority=5
>
Martin,
The old kernel behavior was to call swapout as soon as max_mapped became zero and
never finished shrinking cache upto nr_pages. This change adds some swap pressure
back to the system based on the whether or not we managed to find nr_pages on
the first (or subsequent) max_scan pages.
By changing DEF_PRIORITY in the above patch piece to a fixed value of 5, 4, or 3 you
can see the affects of the change on the amount of swap used in my test case with
a kernel build with various number of seti clients running.
A lower number means less swap pressure and more page cache shrinkage.
Martin
STOCK MH KERNEL.d MH KERNEL.d MH KERNEL.d MH KERNEL.d
prior = 5 prior = 4 prior = 3 prior = 2,1
CLEAN 1.1M 0.0M 0.0M 0.0M not tested
CACHE 1.1M 0.0M 0.0M 0.0M not tested
SETI 1 1.1M 0.8M 0.0M 0.0M not tested
SETI 2 5.8M 2.5M 1.7M 1.0M not tested
SETI 3 16.2M 4.2M 3.3M 1.9M not tested
SETI 4 18.7M 10.5M 8.9M 4.8M not tested
SETI 5 31.7M 15.3M 12.7M 12.0M not tested
SETI 6 35.3M 25.4M 18.6M 18.2M not tested
SETI 7 38.8M 37.7M 25.3M 27.2M not tested
^ permalink raw reply
* Re: Link kernel module with a library
From: John Levon @ 2002-01-15 1:26 UTC (permalink / raw)
To: linux-kernel; +Cc: mylinuxk
In-Reply-To: <20020114230207.35391.qmail@web14911.mail.yahoo.com>
On Mon, Jan 14, 2002 at 06:02:07PM -0500, Michael Zhu wrote:
> Hello,everyone, can I link a kernel module with a
> library? In my module I need to call the functions
> exported from the .a library. I couldn't link that
> library with my module. Can anyone give me a hand on
> this? Thanks in advance.
(please use kernelnewbies mailing list next time, http://kernelnewbies.org/)
You can't use any user space code that relies on code not included in the kernel.
Give more detail on kernelnewbies of your problem, and we'll explain what you actually
need to do.
regards
john
--
"Now why did you have to go and mess up the child's head, so you can get another gold waterbed ?
You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ..."
^ permalink raw reply
* Re: Penelope builds a kernel
From: John Levon @ 2002-01-15 1:24 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20020115005053.GA16892@faceprint.com>
On Mon, Jan 14, 2002 at 07:50:53PM -0500, Nathan Walp wrote:
> She can't very well patch her vendor kernel, because I sincerely doubt
> the patch will apply cleanly, if this driver is such that it needs a
> patch as opposed to just a module.
If it needs a patch, it's messing with kernel internals and she certainly shouldn't
be trying it without an awareness of the potential interactions, or a "recommended
version" from the patch vendor. So if she needs a really stable configuration,
she needs to punt the problem to departmental support.
If it doesn't need a patch, the sensible and proper solution is to autoconfize the
external module source tree, which can adapt itself to different kernels correctly.
autoconfigure of kernel will definitely be useful to e.g. the users we see in
#kernelnewbies, but it is /not/ the right solution for Tilly, Penelope, Dick Dastardly
or any other of the Wacky Races crew Eric is talking about.
regards
john
--
"Now why did you have to go and mess up the child's head, so you can get another gold waterbed ?
You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ..."
^ permalink raw reply
* arpd not working in 2.4.17 or 2.5.1
From: Amit Gupta @ 2002-01-15 1:08 UTC (permalink / raw)
To: linux-kernel
Hi All,
I am running 2.5.1 kernel on a 2 AMD processor system and have enable
routing messages, netlink and arpd support inside kernel as described in
arpd docs.
Then after making 36 character devices, when I run arpd, it's starts up
but always keeps silent (strace) and the kernel also does not keep it's
256 arp address limit.
Pls help fix it, I need linux to be able to talk to more than 1024
clients.
Thanks in Advance.
Amit
amit.gupta@amd.com
^ permalink raw reply
* Re: MIPS64 status?
From: Jason Gunthorpe @ 2002-01-15 0:08 UTC (permalink / raw)
Cc: linux-mips
In-Reply-To: <20020114150751.B29242@dea.linux-mips.net>
On Mon, 14 Jan 2002, Ralf Baechle wrote:
> On Mon, Jan 14, 2002 at 01:42:22PM -0700, Jason Gunthorpe wrote:
>
> > I have such hardware myself. IMHO the best option is the mips64 kernel and
> > I hope to try it someday. But in practice I'd guess that Ralf's highmem
> > patch is more likely to be usuable first (?).
>
> Depends if you can live with the problems of the current mips64 kernel.
> If you can then it's highmem-free memory managment is certainly the way
> to go. It's also not limited to peanuts numbers of gigabytes but can
> support as much memory as your can tack on a MIPS.
Yep, totally.
I thought about starting with mips64 but it was simpler to go with the
pre-existing processor support in the mips32 kernel. I'd like to patch
mips64 up to support the CPU's I have here, but not this month :>
Could someone quickly comment on how it is running? Can it boot normal 32
bit user space OK? I know with sparc64 there were (are?) a number of
problems with missing 32 bit syscall translations for some obscure
things..
Jason
^ permalink raw reply
* Re: [Linux-ia64] Help with Ingo scheduler on IA64
From: Nick Pollitt @ 2002-01-15 1:07 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590698805816@msgid-missing>
What .config are you using? I grabbed the defconfig-bigsur-mp
and compiled with your patch (had to disable DEVFS_DEBUG). The
kernel doesn't get very far into the boot, less than a second,
and it fails. Of course you said it would. But I couldn't get
any useful info from the console so I ran the kernel in medusa.
In case you try this, it executes to about 15301000. Then it
fails in acpi_hw_low_level_read. I also tried with the kernel
patch I sent out Friday, which dies much sooner than this. But
it's definitely not getting into schedule in my machine.
Did you config off other stuff (all the ACPI)?
Nick
On Mon, Jan 14, 2002 at 07:23:31PM +0100, Erich Focht wrote:
> Hi,
>
> I don't think that runqueues(cpu)->idle is set when you try to access it
> from head.S. It is much easier to reintroduce init_tasks and leave head.S
> as it is. Then no changes are needed in Ingo's patch for sched.h and
> sched.c. Ingo, could you please comment?
>
> Please find attached an ia64 patch which should be applied over
> 2.4.17 + ia64 + sched-O1-2.4.17-H7.patch
>
>
> It doesn't boot yet, the system (2CPU BigSur) crashes in
> schedule() <- cpu_idle() <- rest_init() <- start_kernel()
> Maybe somebody has an idea?
>
> Thanks,
>
> Erich
>
> ---
> Erich Focht <efocht@ess.nec.de>
> NEC European Supercomputer Systems, European HPC Technology Center
>
--
Nick Pollitt phone: 650.933.7406
Scalable Linux Project fax: 650.932.0317
Silicon Graphics, Inc. npollitt@engr.sgi.com
^ permalink raw reply
* Re: memory-mapped i/o barrier
From: Jesse Barnes @ 2002-01-15 1:02 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linux-kernel
In-Reply-To: <20020114062454.GA18794@krispykreme>
On Mon, Jan 14, 2002 at 05:24:54PM +1100, Anton Blanchard wrote:
> Can loads/stores also complete out of order to IO? (the example just shows
> a store from one cpu passing one from another cpu)
I'm not sure what you mean, do you have an example?
> On ppc32/ppc64 this can happen, it is fixed up in the low level pci
> routines. Is there a case where you cant wrap it up in the low level
> routines like ppc32/ppc64?
You mean in each outX routine you essentially do an mmiob()?
Jesse
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: yodaiken @ 2002-01-15 0:59 UTC (permalink / raw)
To: george anzinger
Cc: yodaiken, Roman Zippel, Rob Landley, Robert Love, Alan Cox, nigel,
Andrew Morton, linux-kernel
In-Reply-To: <3C4367EA.A52D6360@mvista.com>
On Mon, Jan 14, 2002 at 03:21:14PM -0800, george anzinger wrote:
> > > How is that changed? AFAIK inserting more schedule points does not
> > > change the behaviour of the scheduler. The niced app will still get its
> > > time.
> >
> > How many times can an app be preempted? In a non preempt kernel
> > is can be preempted during user mode at timer frequency and no more
>
> Uh, it can be and is preempted in user mode by ANY interrupt, be it
> keyboard, serial, lan, disc, etc. The kernel looks for need_resched at
> the end of ALL interrupts, not just the timer interrupt.
Ouch.
^ permalink raw reply
* 2.4.17 tulip multiport-patch
From: Christoph Dworzak @ 2002-01-15 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tulip
Hi
After lots of Headscratching, I found this little bug:
replace line 1642 of tulip_core.c:
irq = last_irq;
with
dev->irq = irq = last_irq;
It's a hack for Multiport-NICs where only the first one contains
an EEPROM (I have a Adaptec ANA-6944A/TX). It puts other ports
on the same irq as the first one, but it forgot to actually set
it in the dev-structure...
With this correction my Firewall works like a champ now (before
it crashed immediately when activating the second port of the
multiport-nic).
While searching for this Bug, I also tried the de4x5-driver.
It worked, but with troubles. It sets the MAC-Address of all
the other ports to the MAC of the first port + 1. ALL of them
to the same MAC!
I tried to find out why, but I didn't find this in the code
(I found where it adds this 1, but didn't see why it doesn't
increase it further for further ports...)
Don't know if this is related:
While using the de4x5-driver, my system-load climbed steadily
up. After 3 Days it was at 99.5%.
Top didn't show any processes using this time, but the Computer
was reaaaaaly slow (pressing a key took several seconds until
it appeared on the console...)
This was repeatable. -> Reboot every other day :(
If this happens again, how do I find out what's using the CPU?
(I tried top, vmstat, free, but nothing unusual showed up beside
the system-% in top).
bye
dworz
Config (two Computers A and B):
A Amd-k6/300, 64MB
B Dual PIII-600, 512MB
both with ANA-6944A/TX + 2 other tulips
both RH7.2 with all updates as of 1.1.02
kernel 2.4.9-13 (the tulip-bug is still in 2.4.18pre3)
Computer B would not slow down with DE4x5, but maybe it wasn't
running long enough yet...
Both crashed with tulip.
^ permalink raw reply
* RE: MIPS64 status?
From: Jason Gunthorpe @ 2002-01-14 23:59 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mips
In-Reply-To: <NEBBLJGMNKKEEMNLHGAICENCCEAA.mdharm@momenco.com>
On Mon, 14 Jan 2002, Matthew Dharm wrote:
> Does this mean we could map PCI memory/IO addresses above 4G and have
> it work?
Ooh, don't go there :> We looked at that and actually did it then backed
it out.
The PCI spec (particuarly PCI-X) tries to make it possible, but in a
general system with PCI sockets/etc it is just is not feasible. PCI
bridges need to be located below 4G, as do the majority of devices made.
There is also a performance hit for having device registers > 4G.
You'd definately need the mips64 kernel to do that, or use ugly wired TLB
entries with normal mips.
Jason
^ 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.