* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Davide Libenzi @ 2002-01-15 3:27 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Ingo Molnar, lkml, Dave Jones
In-Reply-To: <20020115031905.01B0624AC1@oscar.casa.dyndns.org>
On Mon, 14 Jan 2002, Ed Tomlinson wrote:
> On January 14, 2002 09:33 pm, Davide Libenzi wrote:
> > try to replace :
> >
> > PRIO_TO_TIMESLICE() and RT_PRIO_TO_TIMESLICE() with :
> >
> > #define NICE_TO_TIMESLICE(n) (MIN_TIMESLICE + ((MAX_TIMESLICE - \
> > MIN_TIMESLICE) * ((n) + 20)) / 39)
> >
> >
> > NICE_TO_TIMESLICE(p->__nice)
>
> Not sure about this change. gkrellm shows the compile getting about 40%
> cpu. Best result here seems to be with a larger range of timeslices. ie
> 1-15 ((10*HZ)/1000...) instead lets the compile get 80% of the cpu. wonder
> if this might be the way to go?
What's the MIN/MAX_TIMESLICE range that you used to get 80% of cpu ?
- Davide
^ permalink raw reply
* Re: [PATCH] O_DIRECT with hardware blocksize alignment
From: Joel Becker @ 2002-01-15 3:21 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Joel Becker, Marcelo Tosatti, lkml
In-Reply-To: <20020112133122.I1482@inspiron.school.suse.de>
On Sat, Jan 12, 2002 at 01:31:22PM +0100, Andrea Arcangeli wrote:
> On Wed, Jan 09, 2002 at 07:56:07PM +0000, Joel Becker wrote:
> > min(I/O alignment, s_blocksize) is used as the effective
> > blocksize. eg:
> >
> > I/O alignment s_blocksize final blocksize
> > 8192 4096 4096
> > 4096 4096 4096
> > 512 4096 512
>
> this falls in the same risky category of the vary-I/O patch from Badari
> (check the discussion on l-k) for rawio, so to make it safe it also will
How so? All I/O is at the computed blocksize. In every
request, the size of each I/O in the kiovec is the same. The
computation is done upon entrance to generic_file_direct_IO, and it is
kept that way. You don't have bh[0]->b_size = 512; bh[1]->b_size =
4096;
Hmm, maybe you mean things like that rumoured 3-ware issue. I
dunno. I do know that this code seems to work just fine with ide,
aha7xxx, and the qlogic driver. Certain software really wants to use
O_DIRECT, and they align I/O on 512byte boundaries. So any scheme that
fails this when it doesn't have to is a problem.
> aligned I/O, but still large I/O) So I suggest you to check Badari's
> stuff and the thread on l-k and to make a new patch incremental with his
I've added myself to that thread as well.
Joel
--
"Vote early and vote often."
- Al Capone
http://www.jlbec.org/
jlbec@evilplan.org
^ permalink raw reply
* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Ed Tomlinson @ 2002-01-15 3:19 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Ingo Molnar, lkml, Dave Jones
In-Reply-To: <Pine.LNX.4.40.0201141829230.937-100000@blue1.dev.mcafeelabs.com>
On January 14, 2002 09:33 pm, Davide Libenzi wrote:
> try to replace :
>
> PRIO_TO_TIMESLICE() and RT_PRIO_TO_TIMESLICE() with :
>
> #define NICE_TO_TIMESLICE(n) (MIN_TIMESLICE + ((MAX_TIMESLICE - \
> MIN_TIMESLICE) * ((n) + 20)) / 39)
>
>
> NICE_TO_TIMESLICE(p->__nice)
Not sure about this change. gkrellm shows the compile getting about 40%
cpu. Best result here seems to be with a larger range of timeslices. ie
1-15 ((10*HZ)/1000...) instead lets the compile get 80% of the cpu. wonder
if this might be the way to go?
Ed
^ permalink raw reply
* Re: [PATCH] PAGE_SIZE IO for RAW (RAW VARY)
From: Joel Becker @ 2002-01-15 3:16 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Alan Cox, linux-kernel
In-Reply-To: <200201102115.g0ALF1e28859@eng2.beaverton.ibm.com>
On Thu, Jan 10, 2002 at 01:15:01PM -0800, Badari Pulavarty wrote:
> The issue with my (mostly) PAGE_SIZE RAW IO patch is, it could generate
> buffer heads with different b_size in a single IO request. Jens & Ben
> have concerns about some of the low level drivers not able to handle
> these. (it would be hard to analyse all the drivers to verify this).
>
> So, Andrea suggested we add a flag in "blk_dev" structure. Only the
> drivers which support variable size buffer heads in a single IO will
> set it. My RAW VARY patch will use this flag to see if I can do
> RAW VARY or not. Makes sense ?
The way I handled it in my O_DIRECT code for the same task (do
the largest I/O you can, instead of a hardcoded 512 or sw_blocksize) was
to merely choose the minimum alignment. See the patch in
<20020109195606.A16884@parcelfarce.linux.theplanet.co.uk>. In your
approach, you want leading blocks to be aligned at 512 or so, then all
4k aligned I/Os to be 4k size, then the trailing I/Os are aligned again
at their size. My approach was 'if aligned at 512, do all 512'. It is
slower than your approach for large I/Os aligned on 512, but it also
has the property of submitting identical blocksizes in one request.
Andrea has suggested that I work with you to be incremental on
top of your code. This would include managing a flag bit to decide if a
device can handle variable I/O sizes in one request. The issue I have
with that is that in the O_DIRECT case, the fallback is failure, not
slow I/O. IOW, in rawio, if the flag is false, you issue all I/Os with
a 512 blocksize. That's slow. However, in O_DIRECT, if the flag is
false, the sw_blocksize is 4096, and the alignment is 512, you fail with
EINVAL. That is bad. In my current patch, the O_DIRECT I/O would
succeed at a 512 byte blocksize. However, my patch doesn't touch rawio
at all.
Please have a look at my patch and maybe we can work on merging
our efforts.
Joel
--
"The first thing we do, let's kill all the lawyers."
-Henry VI, IV:ii
http://www.jlbec.org/
jlbec@evilplan.org
^ permalink raw reply
* highmem=system killer, 2.2.17=performance killer ?
From: Klaus Meyer @ 2002-01-15 3:13 UTC (permalink / raw)
To: linux-kernel
Sorry, i'm a little bit confused now after reading all comments in this
list since
the release of kernel 2.4.17 (without patch) concerning problems in vm +
swap.
Perhaps somebody with more kernel experience can give a hint to clarify
the situation.
i've got serious problems using 2.4.x kernels using highmem support.
It seems to me that i'm not the only one, but the difference to most
other ones is,
that i can't use highmem because the system performance is terrible
slow.
the testbed:
1) Asus CUR-DLS (Server Set LE III) with two 1Ghz Pentiums, 2GB of ram
Suse 7.3, Redhat
7.2 Kernel 2.4.7, 2.4.16, official 2.4.17 i(without patch) in
different versions
(smp,no_smp,4GB,64GB highmem support)
2) Asus A7V 900 Mhz Athlon, 256 MB of RAM Suse 7.0, Kernel 2.2.16
2x DGE-500SX (Gigabit Ethernet)
my test: copy 2.6 GB of data from machine b) to machine a) via rcp or
nfs
using the gigabit ethernet network
a) using redhat 7.2 with kernel 2.4.7 on machine 1)
the copy process runs fine until 1.4 GB are cached (30 MB/s)
after that the performance is degraded to unusability of the system
(very high load, network throuput < 100k/s)
b) using Suse 7.3 with kernel 2.4.16 on machine 1)
booting into runlevel 3 is a pain, loading modules become very slow
after starting the copy process the load of the machine a) will
raise and raise and raise ... here a snapshot of top as long as it
was possible to get one:
-----------------------------------------------------------------------------
9:17pm up 28 min, 2 users, load average: 1.42, 0.36,
0.12
36 processes: 31 sleeping, 5 running, 0 zombie, 0 stopped
CPU0 states: 1.2% user, 100.3% system, 0.0% nice, -1.-5% idle
CPU1 states: 5.2% user, 145.0% system, 0.0% nice, -50.-3% idle
Mem: 2061536K av, 410072K used, 1651464K free, 0K shrd, 20964K
buff
Swap: 136512K av, 0K used, 136512K free 359084K
cached
-----------------------------------------------------------------------------
i didnt know that it seems to be possible to get a negative idle value
???
c) using Suse 7.3 with kernel 2.4.17 in all configurations (smp,no_smp,
4,64 GB highmem support on machine 1)
the same as in b)
I just want to state that there were no oops, so the system were always
running but
inacceptable slow, eg starting xosview leads to a relativly high load:
-----------------------------------------------------------------------------
4:34am up 17 min, 1 user, load average: 0.16, 0.23, 0.26
35 processes: 33 sleeping, 1 running, 1 zombie, 0 stopped
CPU0 states: 23.0% user, 5.0% system, 0.0% nice, 70.1% idle
CPU1 states: 13.0% user, 6.0% system, 0.0% nice, 79.1% idle
Mem: 2061656K av, 37676K used, 2023980K free, 0K shrd, 7628K
buff
Swap: 136512K av, 0K used, 136512K free 11876K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
755 root 11 0 1484 1484 1176 S 21.8 0.0 0:21
xosview.bin
-----------------------------------------------------------------------------
Then i shrinked the available memory to 1024M using the mem= boot
parameter.
The result was amazing:
the above mentioned configurations lead to the following details:
all configuration a) b) c) were running flawless without any performance
losses.
the network throughput of configuration a) and b) was constantly at
above 30MB/s, but
using kernel 2.4.17 (configuration c) degrades the network throughput to
15 MB/s.
all in all there are two questions left:
a) what can i do to use highmem support (which patches do i have to
apply ?)
b) Does have other users made experiences with network performance
degration using 2.2.17
instead of 2.2.16 ?
Any hints ?
thanx in advance
Klaus
^ permalink raw reply
* Re: Penelope builds a kernel
From: John Levon @ 2002-01-15 2:07 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20020115013954.GB3814@cpe-24-221-152-185.az.sprintbbd.net>
On Mon, Jan 14, 2002 at 06:39:54PM -0700, Tom Rini wrote:
> 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)
autoconf code already exists for this, it's a non-problem. Note they must use
the config in the header file of the vendor-provided kernel source tree, not
/boot/config-`uname -r`
There are two cases:
1) the vendor source tree is installed and set up with the right config -> use header file
2) it's installed and the config has changed. -> use header file
I don't see a point in ever looking at /boot/config-`uname -r` instead of
the source tree, given that we must compile against a tree configured like the
eventual running kernel anyway.
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: [RFC] klibc requirements
From: Albert D. Cahalan @ 2002-01-15 3:08 UTC (permalink / raw)
To: Felix von Leitner; +Cc: Greg KH, linux-kernel, andersen
In-Reply-To: <20020109042331.GB31644@codeblau.de>
Felix von Leitner writes:
> My understanding of what "initramfs programs" actually means is vague at
> best. Are these just programs that are intended to work in an initial
> ram disk? Or is it a special collection that is included in the kernel
> distribution?
1. special collection by default
2. user-specified as desired
I think the dietlibc idea has to be scrapped so we can run BSD apps.
(and others maybe, but I'm not looking to start a flame war)
uClibc is LGPL, so traditional 4-clause BSD licensed code can be
linked with it.
> there are no legacy requirements to cater to. We can write code without
> printf and stdio, for example. Also, we probably don't need regular
> expressions or DNS. Those are the big space hogs when linking
> statically against a libc. In the diet libc, all of the above are very
> small, but avoiding them in the first place is better then optimizing
> them for small size.
DNS is very good to have. There are many things one might want
to specify by name. NFS servers, NIS servers, SMB servers, and
even the machine itself to get an IP via DNS.
> This may look like a good idea, but dynamic linking should be avoided.
> Trust me on this. While it is possible to squeeze the dynamic loader
> down to below 10k, 10k really is a lot of code. And empty program with
> the diet libc is way below 1k on x86. So to reap the benefit of dynamic
> linking, you would need a lot of programs. Also please note that -fPIC
> makes code larger. And we need to keep symbols around, which makes up a
> substantial part of the shared diet libc.
a.out
Even with ELF, you shouldn't need that 10 kB. Treat ELF like a.out,
getting rid of the -fPIC stuff in favor of offsets assigned when
you build the initramfs. Dynamic linking should be:
open
mmap
mmap
close
You know the file to open. You know what offset you need it at.
There isn't any need for symbols. OK, that's half-dynamic,
but it gets the job done.
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: george anzinger @ 2002-01-15 3:07 UTC (permalink / raw)
To: Daniel Phillips
Cc: yodaiken, Momchil Velikov, Arjan van de Ven, Roman Zippel,
linux-kernel
In-Reply-To: <E16QC5P-0000nO-00@starship.berlin>
Daniel Phillips wrote:
>
> On January 14, 2002 10:09 am, yodaiken@fsmlabs.com wrote:
> > UNIX generally tries to ensure liveness. So you know that
> > cat lkarchive | grep feel | wc
> > will complete and not just that, it will run pretty reasonably because
> > for UNIX _every_ process is important and gets cpu and IO time.
> > When you start trying to add special low latency tasks, you endanger
> > liveness. And preempt is especially corrosive because one of the
> > mechanisms UNIX uses to assure liveness is to make sure that once a
> > process starts it can do a significant chunk of work.
>
If I read this right, your complaint is not with preemption but with
scheduler policy. Clearly both are needed to "assure liveness".
Another way of looking at preemption is that is enables a more
responsive and nimble scheduler policy (afterall it is the scheduler
that decided that task A should give way to task B. All preemption does
is to allow that to happen with greater dispatch.) Given that, we can
then discuss what scheduler policy should be.
--
George george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
^ permalink raw reply
* [PATCH] PATH_MAX Poxification.
From: Rusty Russell @ 2002-01-15 3:08 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
As went in to 2.5.2...
Thanks!
Rusty.
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.4.14/include/linux/limits.h working-2.4.14-pathmax/include/linux/limits.h
--- linux-2.4.14/include/linux/limits.h Thu Jul 29 03:30:10 1999
+++ working-2.4.14-pathmax/include/linux/limits.h Wed Nov 21 10:59:37 2001
@@ -11,7 +11,7 @@
#define MAX_CANON 255 /* size of the canonical input queue */
#define MAX_INPUT 255 /* size of the type-ahead buffer */
#define NAME_MAX 255 /* # chars in a file name */
-#define PATH_MAX 4095 /* # chars in a path name */
+#define PATH_MAX 4096 /* # chars in a path name including nul */
#define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
#define RTSIG_MAX 32
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.4.14/fs/dcache.c working-2.4.14-pathmax/fs/dcache.c
--- linux-2.4.14/fs/dcache.c Thu Oct 4 15:57:36 2001
+++ working-2.4.14-pathmax/fs/dcache.c Wed Nov 21 12:04:18 2001
@@ -1262,7 +1262,7 @@
panic("Cannot create buffer head SLAB cache");
names_cachep = kmem_cache_create("names_cache",
- PATH_MAX + 1, 0,
+ PATH_MAX, 0,
SLAB_HWCACHE_ALIGN, NULL, NULL);
if (!names_cachep)
panic("Cannot create names SLAB cache");
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.4.14/fs/namei.c working-2.4.14-pathmax/fs/namei.c
--- linux-2.4.14/fs/namei.c Thu Oct 18 07:46:29 2001
+++ working-2.4.14-pathmax/fs/namei.c Wed Nov 21 10:57:58 2001
@@ -99,16 +99,17 @@
* kernel data space before using them..
*
* POSIX.1 2.4: an empty pathname is invalid (ENOENT).
+ * PATH_MAX includes the nul terminator --RR.
*/
static inline int do_getname(const char *filename, char *page)
{
int retval;
- unsigned long len = PATH_MAX + 1;
+ unsigned long len = PATH_MAX;
if ((unsigned long) filename >= TASK_SIZE) {
if (!segment_eq(get_fs(), KERNEL_DS))
return -EFAULT;
- } else if (TASK_SIZE - (unsigned long) filename < PATH_MAX + 1)
+ } else if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
len = TASK_SIZE - (unsigned long) filename;
retval = strncpy_from_user((char *)page, filename, len);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: george anzinger @ 2002-01-15 3:01 UTC (permalink / raw)
To: Oliver.Neukum
Cc: Robert Love, Momchil Velikov, yodaiken, Daniel Phillips,
Roman Zippel, linux-kernel
In-Reply-To: <16QFsj-206pZgC@fwd03.sul.t-online.com>
Oliver Neukum wrote:
>
> > Well, semaphores block. And we have these races right now with
> > SCHED_FIFO tasks. I still contend preempt does not change the nature of
> > the problem and it certainly doesn't introduce a new one.
>
> But it does:
>
> down(&sem);
> do_something_that_cannot_block();
> up(&sem);
>
> Will stop a SCHED_FIFO task for a definite amount of time. Only
> until it returns from the kernel to user space at worst.
>
> If do_something_that_cannot_block() can be preempted, a SCHED_FIFO
> task can block indefinitely long on the semaphore, because you have
> no guarantee that the scheduler will ever again select the the preempted task.
> In fact it must never again select the preempted task as long as there's
> another runnable SCHED_FIFO task.
>
This is not true, and if it is is a scheduler bug. When a task (any
task) gets preempted it is not moved from the front of its queue, thus,
in this case, the FIFO task will still be the fitst task at its prioity
to run. Also, it can only be preempted by another real time task of
higher priority. Now it is possible that that task may block on the
same sem, but this is simple priority inversion and has nothing to do
with the sem holder being FIFO, RR or any thing else. In other words
preemption does NOT change a FIFO (or any other) task's position in the
dispatch queue.
--
George george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: peter @ 2002-01-15 2:58 UTC (permalink / raw)
To: linux-kernel
I don't mind how people do it, but there are currently two significant
penalties associated with modules on x86. I think other architectures
have analogues.
1) The main kernel is contiguous in physical memory and is mapped with
large (4 MB) pages. This reduces pressure on the TLB. Modules are
loaded in vmalloc memory, which uses small pages, and therefore
competes for TLB space. This is a performance penalty, especially
as most current machines have undersized TLBs already. (A 64-entry
TLB with 4K pages maps 256K at a time. On-chip L2 caches are this
large or larger. Thus, as a crude approximation, every L2 miss also
causes a TLB miss.)
Also, vmalloc space is limited, and contributes to the "why isn't
the kernel seeing all of my 1 GB?" question.
2) Space for module code is allocated in page units. Thus, each module
wastes an average of 2K. If I'm going to have dozens of modules
loaded, small machines are going to notice.
On a related subject, I'd like a kernel image to consist of a series
of concatenated "chunks". The first one is the kernel proper, and then
come various modules and initrd image(s). (There may be an "EOF" chunk,
or just the absence of a magic number.)
All the boot loader has to do is copy the image into contiguous memory
and jump to it. The start of the image (ideally, it'd be PIC) then
relocates itself to wherever it wants and starts assembling the pieces.
Whether this is done by a sort of linker before the kernel boots, or
if the chunks are all ramdisk components and form a userland that the
kernel boots to which assemble the rest of the kernel is not particularly
important. I just want the unnecessary bits to get thrown away once
we've booted. (Kernel bloat should NOT be designed in.)
That would make assembling a custom boot image simple enough for a fancy
boot loader (or fancy tftp server) to do.
^ permalink raw reply
* Re: Defining new section for bus driver init
From: Dave Jones @ 2002-01-15 2:55 UTC (permalink / raw)
To: Patrick Mochel; +Cc: Linux Kernel
> 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?
Well, it chops out a load of ugly ifdefs, and makes adding support
for a new bus less intrusive than it currently is. I quite like it.
> 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.
I think you hit the nail on the head with the subject line.
struct BusDriver also conjures up amusing[*] imagery.
One thing I'm wondering about though. Is it possible for a new
bus to be added after boot ? Docking stations etc show up as
children on the root PCI bus, so that shouldn't be an issue.
Ah! hotplug PCI USB controller ?
Dave.
[*] I'm easily amused.
--
Dave Jones. http://www.codemonkey.org.uk
SuSE Labs.
^ permalink raw reply
* 2.4.18-pre3-ac2 performance regression(?) vs. 2.4.17
From: Florin Iucha @ 2002-01-15 2:53 UTC (permalink / raw)
To: Rik van Riel, Alan Cox; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
Rik, Alan,
I have downloaded 2.4.18-pre3-ac2 out of curiosity for the VM and IDE
performance.
As a "benchmark" I ran hdparm -Tt /dev/hda. The results were surprising:
2.4.17
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.86 seconds =148.84 MB/sec
Timing buffered disk reads: 64 MB in 3.95 seconds = 16.20 MB/sec
Timing buffer-cache reads: 128 MB in 0.90 seconds =142.22 MB/sec
Timing buffered disk reads: 64 MB in 4.05 seconds = 15.80 MB/sec
Timing buffer-cache reads: 128 MB in 0.88 seconds =145.45 MB/sec
Timing buffered disk reads: 64 MB in 4.00 seconds = 16.00 MB/sec
2.4.18-pre3-ac2
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.99 seconds =129.29 MB/sec
Timing buffered disk reads: 64 MB in 3.90 seconds = 16.41 MB/sec
Timing buffer-cache reads: 128 MB in 0.93 seconds =137.63 MB/sec
Timing buffered disk reads: 64 MB in 4.03 seconds = 15.88 MB/sec
Timing buffer-cache reads: 128 MB in 0.92 seconds =139.13 MB/sec
Timing buffered disk reads: 64 MB in 3.90 seconds = 16.41 MB/sec
So while I see a slight (un)expected improvement in IDE performance, I
also see a degradation in memory? performance.
The box is a PIII/700MHz laptop with 256 Mb RAM. hdparm is version 4.5
Cheers,
florin
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Linux-2.5.2
From: Linus Torvalds @ 2002-01-15 2:45 UTC (permalink / raw)
To: Kernel Mailing List
Ok, lots of various changes between 2.5.1->2, mainly in bio, kdev_t and
scheduler (and several USB updates).
Linus
----
final:
- Matt Domsch: combine common crc32 library
- Pete Zaitcev: ymfpci update
- Davide Libenzi: scheduler improvements
- Al Viro: almost there: "struct block_device *" everywhere
- Richard Gooch: devfs cpqarray update, race fix
- Rusty Russell: PATH_MAX should include the final '\0' count
- David Miller: various random updates (mainly net and sparc)
pre11:
- Davide Libenzi, Ingo Molnar: scheduler updates
- Greg KH: USB update
- Jean Tourrilhes: IrDA and wireless updates
- Jens Axboe: bio/block updates
pre10:
- Kai Germaschewski: ISDN updates
- Al Viro: start moving buffer cache indexing to "struct block_device *"
- Greg KH: USB update
- Russell King: fix up some ARM merge issues
- Ingo Molnar: scalable scheduler
pre9:
- Russell King: large ARM update
- Adam Richter et al: more kdev_t updates
pre8:
- Greg KH: USB updates
- various: kdev_t updates
- Al Viro: more bread()/filesystem cleanups
pre7:
- Jeff Garzik: fix up loop and md for struct kdev_t typechecking
- Jeff Garzik: improved old-tulip network driver
- Arnaldo: more scsi driver bio updates
- Kai Germaschewski: ISDN updates
- various: kdev_t updates
pre6:
- Davide Libenzi: nicer timeslices for scheduler
- Arnaldo: wd7000 scsi driver cleanups and bio update
- Greg KH: USB update (including initial 2.0 support)
- me: strict typechecking on "kdev_t"
pre5:
- Dave Jones: more merging, fix up last merge..
- release to sync with Dave
pre4:
- Jens Axboe: more bio updates, fix some request list bogosity under load
- Al Viro: export seq_xxx functions
- Manfred Spraul: include file cleanups, pc110pad compile fix
- David Woodhouse: fix JFFS2 write error handling
- Dave Jones: start merging up with 2.4.x patches
- Manfred Spraul: coredump fixes, FS event counter cleanups
- me: fix SCSI CD-ROM sectorsize BIO breakage
pre3:
- Christoph Hellwig: scsi_register_module cleanup
- Mikael Pettersson: apic.c LVTERR fixes
- Russell King: ARM update (including bio update for icside)
- Jens Axboe: more bio updates
- Al Viro: make ready to switch bread away from kdev_t..
- Davide Libenzi: scheduler cleanups
- Anders Gustafsson: LVM fixes for bio
- Richard Gooch: devfs update
pre2:
- Al Viro: task-private namespaces, more cleanups
pre1:
- me: revert the "kill(-1..)" change. POSIX isn't that clear on the
issue anyway, and the new behaviour breaks things.
- Jens Axboe: more bio updates
- Al Viro: rd_load cleanups. hpfs mount fix, mount cleanups
- Ingo Molnar: more raid updates
- Jakub Jelinek: fix Linux/x86 confusion about arg passing of "save_v86_state" and "do_signal"
- Trond Myklebust: fix NFS client race conditions
^ permalink raw reply
* Re: Penelope builds a kernel
From: Benjamin LaHaise @ 2002-01-15 2:36 UTC (permalink / raw)
To: Eric S. Raymond, linux-kernel
In-Reply-To: <20020114205307.E24120@thyrsus.com>
On Mon, Jan 14, 2002 at 08:53:07PM -0500, Eric S. Raymond wrote:
> I don't understand what you think you're seeing, but I am sure of
> this; if I had been enough of a drug-addled lunatic to allow fetchmail
> to delete mail before getting a positive acknowledge from the
> downstream MTA, someone in the pool of over two thousand people who have sent
> me bug reports and patches would have called me on it some time in the
> six years of production use well before *you* entered the picture.
Uhm, as someone who has run a number of mailing lists for the past 6
years, I've seen fetchmail induced bounces numerous times, and 99% of
the time they're because the damn thing should default to a
--never-send-bounces-to-anyone.
> It's likely you're being hosed by an MTA that's sending back bogus 2xx
> responses. That's happend before. Fetchmail can't magically cope
> with MTAs that tell it lies.
That's part of what you have to deal with by being a hybrid MTA/MUA:
your error handling must be directed at the user of fetchmail, not the
originator of the message. The originator of the message has no control
over the misdelivery of the message due to user config file error, so
why should they receive the error? Bounces like these are very
difficult to determine what the address causing trouble is because of
the fact that fetchmail *is* an MUA -> it should not behave as if it is
purely an MTA.
> Fetchmail *already works the way you recommend* -- as any idiot can
> verify by reading the short section of the main driver loop where
> dispatch and delete takes place. That's been an invariant of the code
> since day one, and you thus clearly have no bloody idea what you are
> flaming about.
Good, at least that part of my understanding of it was wrong, and I'm
glad to hear that. But the behaviour is still indistinguishable from
the gross misdesign that it feels like. Namely, ask yourself why it
loses mail if the user makes a typo in the config file on their first
try? Who gets the bounce? Why should the message be deleted instead
of merely deferred?
Besides, I think you're trying to solve the wrong problem. A good many
readers of linux-kernel don't want to start seeing posts from Aunt Tillie
and would rather leave this ease of use issue to the distributions that
already make it easy as pie.
-ben
^ permalink raw reply
* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Davide Libenzi @ 2002-01-15 2:33 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Ingo Molnar, lkml, Dave Jones
In-Reply-To: <20020115021837.4A63969E@oscar.casa.dyndns.org>
On Mon, 14 Jan 2002, Ed Tomlinson wrote:
> On January 14, 2002 08:50 pm, 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?
> >
> > Doh !
> > Did you set this ?
> >
> > #define MIN_TIMESLICE (10 * HZ / 1000)
>
> I set:
>
> #define MIN_TIMESLICE 10
>
> Now I am tring
>
> #define MIN_TIMESLICE 1
>
> which, looksing at monitors, gives about 80% cpu to the compile
try to replace :
PRIO_TO_TIMESLICE() and RT_PRIO_TO_TIMESLICE() with :
#define NICE_TO_TIMESLICE(n) (MIN_TIMESLICE + ((MAX_TIMESLICE - \
MIN_TIMESLICE) * ((n) + 20)) / 39)
NICE_TO_TIMESLICE(p->__nice)
I'm currently running it on my machine but i don't want that this changes
that 'liquid' interactive feel that me and Ingo have got with the new code
- Davide
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Eric S. Raymond @ 2002-01-15 2:06 UTC (permalink / raw)
To: Alan Cox
Cc: Rob Landley, Charles Cazabon, Linux Kernel List, Eli Carter,
Michael Lazarou (ETL)
In-Reply-To: <E16QGUy-0003Kh-00@the-village.bc.nu>
Alan Cox <alan@lxorguk.ukuu.org.uk>:
> I simply don't understand what you are trying to build and why it is hard.
Don't understand it? Download it, follow the directions, and see.
It's not that hard. Given Giacomo's table of probes it only took me about
two days to get it 85% of the way there. The remaining 15% is partly
issues with rulebase bugs that it exposes, and partly issues with what
to do about the possibility of ISA hardware that is not directly probeable.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance? Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and tyrants.
-- Thomas Jefferson, letter to Col. William S. Smith, 1787
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Bruce Harada @ 2002-01-15 2:22 UTC (permalink / raw)
To: Rob Landley; +Cc: esr, linux-kernel
In-Reply-To: <20020114234129.MGOI23959.femail47.sdc1.sfba.home.com@there>
On Mon, 14 Jan 2002 10:39:25 -0500
Rob Landley <landley@trommello.org> wrote:
> On Monday 14 January 2002 06:02 pm, Bruce Harada wrote:
> > On Mon, 14 Jan 2002 17:34:23 -0500
> >
> > Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> > worried about whether her kernel supports the Flangelistic2000
SuperDoodad.
>
> I think what Eric's REALLY going for is converting some of the Minesweeper
> Certified Solitaire Experts down at the corner store (and yes there are still
> corner computer stores in mini-malls around the country) over to The Penguin.
Er... if Eric were REALLY going for that, why didn't he use it as an example?
That might actually be a possible real-world situation, whereas all the ones
I've seen so far are so far removed from reality as to be pointless.
Let me put it this way: Requiring Aunt Tillie to configure/compile her kernel
is a *failure* on the part of the vendor. It doesn't matter whether Aunt
Tillie is really Aunt Tillie or your local MSCE. They should not have to do it.
As for adding a driver that's not included in the vendor's kernel, do you
mean that having a Microsoft-trained drone rebuild a kernel specifically for a
certain PC (thus requiring further compilation for any hardware added later)
and including a no-doubt beta driver and then giving it to Aunt Tillie without
any testing beyond the MCSE's PC is a *good* idea?
(I've trimmed the cc line a bit, BTW.)
^ permalink raw reply
* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Ed Tomlinson @ 2002-01-15 2:18 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Ingo Molnar, lkml, Dave Jones
In-Reply-To: <Pine.LNX.4.40.0201141748570.1233-100000@blue1.dev.mcafeelabs.com>
On January 14, 2002 08:50 pm, 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?
>
> Doh !
> Did you set this ?
>
> #define MIN_TIMESLICE (10 * HZ / 1000)
I set:
#define MIN_TIMESLICE 10
Now I am tring
#define MIN_TIMESLICE 1
which, looksing at monitors, gives about 80% cpu to the compile
Ed Tomlinson
^ permalink raw reply
* Unable to compile 2.4.14 on alpha
From: Wakko Warner @ 2002-01-15 2:25 UTC (permalink / raw)
To: linux-kernel
make[2]: Entering directory `/usr/src/2.4.14-test/arch/alpha/math-emu'
make[2]: Nothing to be done for `all_targets'.
make[2]: Leaving directory `/usr/src/2.4.14-test/arch/alpha/math-emu'
make[1]: Leaving directory `/usr/src/2.4.14-test/arch/alpha/math-emu'
ld -static -T arch/alpha/vmlinux.lds -N arch/alpha/kernel/head.o init/main.o init/version.o \
--start-group \
arch/alpha/kernel/kernel.o arch/alpha/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/alpha/math-emu/math-emu.o \
drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o drivers/md/mddev.o \
net/network.o \
/usr/src/2.4.14-test/arch/alpha/lib/lib.a /usr/src/2.4.14-test/lib/lib.a /usr/src/2.4.14-test/arch/alpha/lib/lib.a \
--end-group \
-o vmlinux
arch/alpha/kernel/kernel.o(.exitcall.exit+0x0): undefined reference to `local symbols in discarded section .text.exit'
mm/mm.o(.exitcall.exit+0x0): undefined reference to `local symbols in discarded section .text.exit'
fs/fs.o(.exitcall.exit+0x0): undefined reference to `local symbols in discarded section .text.exit'
fs/fs.o(.exitcall.exit+0x8): undefined reference to `local symbols in discarded section .text.exit'
fs/fs.o(.exitcall.exit+0x10): undefined reference to `local symbols in discarded section .text.exit'
fs/fs.o(.exitcall.exit+0x18): more undefined references to `local symbols in discarded section .text.exit' follow
make: *** [vmlinux] Error 1
[root@kakarot:/usr/src/2.4.14-test] ld --version
GNU ld version 2.11.92.0.12.3 20011121 Debian/GNU Linux
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
[root@kakarot:/usr/src/2.4.14-test] gcc --version
2.95.4
[root@kakarot:/usr/src/2.4.14-test]
gcc 3.0.3 didn't work either (I don't feel that's the problem)
2.4.16 did the same thing, except it was in char.o
I tried to link the kernel by removing arch/alpha/kernel/kernel.o and
replacing with the actual files. the error is in arch/alpha/kernel/srm_env.o
I really need something to work as I have a DAC960 controller that I want to
try.
--
Lab tests show that use of micro$oft causes cancer in lab animals
^ permalink raw reply
* Re: Penelope builds a kernel
From: Eric S. Raymond @ 2002-01-15 1:53 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: linux-kernel
In-Reply-To: <20020114183820.G30639@redhat.com>
Benjamin LaHaise <bcrl@redhat.com>:
> FYI, it's easy to fix, just use the correct ordering of download, transmit,
> delete that sendmail and other MTAs use.
I don't understand what you think you're seeing, but I am sure of
this; if I had been enough of a drug-addled lunatic to allow fetchmail
to delete mail before getting a positive acknowledge from the
downstream MTA, someone in the pool of over two thousand people who have sent
me bug reports and patches would have called me on it some time in the
six years of production use well before *you* entered the picture.
It's likely you're being hosed by an MTA that's sending back bogus 2xx
responses. That's happend before. Fetchmail can't magically cope
with MTAs that tell it lies.
Fetchmail *already works the way you recommend* -- as any idiot can
verify by reading the short section of the main driver loop where
dispatch and delete takes place. That's been an invariant of the code
since day one, and you thus clearly have no bloody idea what you are
flaming about.
Don't take my word for it. Go read the code. Until you've done so,
I suggest you take it off-list before you embarrass yourself further.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
A man who has nothing which he is willing to fight for, nothing
which he cares about more than he does about his personal safety,
is a miserable creature who has no chance of being free, unless made
and kept so by the exertions of better men than himself.
-- John Stuart Mill, writing on the U.S. Civil War in 1862
^ permalink raw reply
* [Linux-ia64] [ANNOUNCE] first prototype of unwind API
From: David Mosberger @ 2002-01-15 2:03 UTC (permalink / raw)
To: linux-ia64
[Note: this announcement is cross-posted to the glibc, gcc, and
linux-ia64 mailing list because I believe this may be of interest to
various people on these lists. This will be the only post of this
sort; all future discussion will happen on the relevant mailing
lists. Thanks for your understanding.]
I'm happy to announce a first prototype implementation of a (mostly)
platform-independent unwind API. The purpose of this API is to
simplify the implementation of applications that need to inspect the
call-chain of a process/thread. The immediate goal is to use this
library to implement routines such as glibc's backtrace() function and
offer a substitute for the unwind implementation currently in gcc (of
course, it will be up to the glibc and gcc maintainers to decide
if/when this is appropriate...).
Originally, the API was intended for the ia64 platform, but the
current draft is platform-independent with the exception of the
manifest constants for register names (there are a couple of
well-known register names that make it possible to implement, e.g.,
backtraces in a completely platform-independent fashion).
The prototype source code is available at:
ftp://ftp.hpl.hp.com/pub/linux-ia64/libunwind-0.0.tar.gz
md5sum: 9a2935bf589331b17cf23defc3e36bbd libunwind-0.0.tar.gz
The current prototype implementation is limited to the ia64 linux
platform and even that version has received only light testing. The
main purpose of this release is to increase the exposure of the API
and to collect feedback. It would also be nice to find people
interested in implementing the API for other platforms (e.g., x86,
Alpha, etc).
For more information, please refer to the README in the top-level
directory of the source distribution.
If this is a topic of interest to you, please consider subscribing to
the "libunwind" mailing list. Again, see the README for details.
For the next steps, I'm planning to create the glue logic needed to
use libunwind for GCC exception handling. Once that is working, I'd
like to do some fairly extensive correctness and performance testing.
Needless to say: any and all feedback is welcome. Note that to limit
SPAM, it is necessary to subscribe to libunwind before you can post to
the list. If you do not wish to do that but still have comments, just
send them directly to me (davidm@hpl.hp.com).
Thanks,
--david
^ permalink raw reply
* Re: [tulip] 2.4.17 tulip multiport-patch
From: Donald Becker @ 2002-01-15 2:03 UTC (permalink / raw)
To: Christoph Dworzak; +Cc: linux-kernel, tulip
In-Reply-To: <20020115020413.B11753@amazing.ch>
On Tue, 15 Jan 2002, Christoph Dworzak wrote:
> 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;
Hmmm, a little bit of bad conversion here. The tulip.c code follows
this section by
dev->irq = irq;
a few lines later.
> While using the de4x5-driver, my system-load climbed steadily
> up. After 3 Days it was at 99.5%.
Check the interrupt count in /dev/interrupts.
> This was repeatable. -> Reboot every other day :(
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
^ permalink raw reply
* Re: Memory problem with bttv driver
From: Stephan von Krawczynski @ 2002-01-15 1:55 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Alan Cox, linux-kernel
In-Reply-To: <Pine.LNX.4.21.0201142245040.2118-100000@localhost.localdomain>
> On Mon, 14 Jan 2002, Stephan von Krawczynski wrote:
> >
> > Ok. So what do we do about it? I mean there are possibly some more
people out
> > there with such a problem, or - to my prediction - there will be
more in the
> > future. I see to possibilities:
> > 1) simply increase it overall. I have not the slightest idea what
the drawbacks
> > are. 2) make it configurable (looks like general setup to me).
> >
> > I could provide a patch for either. Do we want that?
>
> I was waiting for hpa to jump on you for suggesting that! but since
> he hasn't yet done so (publicly), here's his mail when I suggested
it
> a month ago (as a temporary aid while tracking down a similar
problem).
>
> That problem was from NTFS overusing vmalloc (and I think Anton has
> now posted the fix), but NTFS wasn't in your list, and I assume you
> didn't have it in statically.
Nope, no ntfs involved here.
I read the former thread. It was in my mind when trying the increased
VMALLOC_RESERVE, and voila, it worked again. I must admit in your case
I was very much thinking that ntfs should be fixed, and I am pleased
the maintainer thought the same :-)
Unfortunately I do not have a good idea about what to do in days where
the graphics cards have more ram onboard than my last workstation had
in total. If I understood Alans' opinion, he thinks basically the
same, what the heck can you do about such monster cards? I don't know,
other than adjusting the RESERVE-area. I have not really thought about
it right now, but I suspect it would be rather impossible to make a
somehow runtime-scalable area working, which would of course be the
complete solution to the underlying problem.
So, what's left? At least configurable? Anybody with a better idea?
Regards,
Stephan
>
^ permalink raw reply
* 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
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.