* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Larry McVoy @ 2002-12-18 19:45 UTC (permalink / raw)
To: Alan Cox
Cc: Larry McVoy, Linus Torvalds, Dave Jones, Horst von Brand,
linux-kernel, Andrew Morton
In-Reply-To: <200212181942.gBIJgp418497@devserv.devel.redhat.com>
On Wed, Dec 18, 2002 at 02:42:51PM -0500, Alan Cox wrote:
> > On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> > > We've got one - its called linux-kernel.
> >
> > Huh? That's like saying "we don't need a bug database, we have a mailing
> > list". That's patently wrong and so is your statement. If you want
> > reviews you need some place to store them. A mailing list isn't storage.
> >
> > You'll do it however you want of course, but you are being stupid about it.
> > Why is that?
>
> We've got a bug database (bugzilla), we've got a system for seeing what opinion
> appears to be -kernel-list
And exactly how is your statement different than
"we have a system for seeing what bugs appear to be -kernel-list"
?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Alan Cox @ 2002-12-18 19:42 UTC (permalink / raw)
To: Larry McVoy
Cc: Alan Cox, Larry McVoy, Linus Torvalds, Dave Jones,
Horst von Brand, linux-kernel, Andrew Morton
In-Reply-To: <20021218113324.I7976@work.bitmover.com>
> On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> > We've got one - its called linux-kernel.
>
> Huh? That's like saying "we don't need a bug database, we have a mailing
> list". That's patently wrong and so is your statement. If you want
> reviews you need some place to store them. A mailing list isn't storage.
>
> You'll do it however you want of course, but you are being stupid about it.
> Why is that?
We've got a bug database (bugzilla), we've got a system for seeing what opinion
appears to be -kernel-list
^ permalink raw reply
* Re: problems with raidhotgenerateerror
From: Steven Dake @ 2002-12-18 19:34 UTC (permalink / raw)
To: Claudio Fleiner; +Cc: linux-raid
In-Reply-To: <200212180222.gBI2MUD23542@ars.net>
You should try setting the raid device to faulty which will allow
atleast the disk to be hot removed.
Thanks
-steve
Claudio Fleiner wrote:
>I was playing around with raid1 using two loopback devices of 4M each.
>The config file I'm using looks like this:
>
>raiddev /dev/md0
> raid-level 1
> nr-raid-disks 2
> nr-spare-disks 0
> chunk-size 4
> persistent-superblock 1
> device /dev/loop0
> raid-disk 0
> device /dev/loop1
> raid-disk 1
>
>
>Everything works as expected, except that I cannot simulate an error using
>raidhotgenerateerror. The command runs just fine (as confirmed by the following strace,
>(all unnecessary stuff removed):
>
>execve("/home/cfl/prog/raidtools-20010914/raidhotgenerateerror", ["/home/cfl/prog/raidtools-20010914/raidhotgenerateerror", "-c", "c", "/dev/md0", "/dev/loop0"], [/* 58 vars */]) = 0
>open("/dev/md0", O_RDONLY) = 4
>ioctl(4, 0x800c0910, 0x804f948) = 0
>open("/dev/md0", O_RDWR) = 5
>fstat64(5, {st_mode=S_IFBLK|0660, st_rdev=makedev(9, 0), ...}) = 0
>stat64("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
>ioctl(5, 0x92a, 0x700) = 0
>_exit(0) = ?
>
>but /proc/mdstat shows that loop0 is still OK (writing to the md0 device
>does not make a difference) and removing the drive using raidhotremove
>fails):
>
>Personalities : [raid0] [raid1] [raid5]
>read_ahead 1024 sectors
>md0 : active raid1 [dev 07:01][1] [dev 07:00][0]
> 4032 blocks [2/2] [UU]
>
>
>I'm using Redhat 7.2 with a 2.4.19 kernel.
>
>Any idea why this is not working?
>
>Thanks, Claudio
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
>
^ permalink raw reply
* RE: [ACPI] Re: [PATCH] S4bios for 2.5.52.
From: Nigel Cunningham @ 2002-12-18 19:37 UTC (permalink / raw)
To: 'Ducrot Bruno', 'Kai Germaschewski'
Cc: 'Grover, Andrew', linux-kernel, 'Pavel Machek',
acpi-devel
In-Reply-To: <20021218085902.GD1012@poup.poupinou.org>
> Kai, if you see that S4OS is slower, it is probably a bug
> that have to be
> fixed in swsusp.
There does seem to be a problem with the rw_swap_page_sync routine. Perhaps
not on Pavel's machine (:>), but I've experienced painfully slow suspends
too. Performance was helped immensely by applying a concept that I'll credit
Lyle Seaman for - unrolling rw_swap_page_sync and submitting all the IO for
pages then looping again and waiting on each sync. I found with writing 7000
or so pages (a suspend from init S) that something gets triggered to force
the sync about every 3900 pages anyway.
Regards,
Nigel
^ permalink raw reply
* Re: [PATCH]:
From: Ralf Baechle @ 2002-12-18 19:29 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list
In-Reply-To: <m2smwwqf0e.fsf@demo.mitica>
On Wed, Dec 18, 2002 at 02:42:25AM +0100, Juan Quintela wrote:
> PD. Someone can explain me what mean:
> __attribute__ ((__mode__ (__SI__)));
>
> The SI part don't appear in the gcc info pages :(
Single Integer, a 32-bit integer.
Ralf
^ permalink raw reply
* Re: [Linux-ia64] RTC support on ia64
From: Alex Williamson @ 2002-12-18 19:26 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805600@msgid-missing>
Joel GUILLET wrote:
>
> The RTC legacy hardware seems to be on the i870 chipset. And if you don't
> have this one, you may not be able to use it.
Obviously, but that wasn't really my point. What I'm really
after is that on ia64 you really shouldn't be assuming legacy
hardware is present and blindly poking port space and setting up
irqs based on that assumption. Not only might it not work on
a legacy free box, it might break other things. I think you
really need to make some attempt to determine if the hardware is
out there, and I don't see one in the rtc_init path.
Alex
--
Alex Williamson Linux Development Lab
alex_williamson@hp.com Hewlett Packard
970-898-9173 Fort Collins, CO
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Maciej W. Rozycki @ 2002-12-18 19:26 UTC (permalink / raw)
To: Jun Sun; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20021218105148.E6061@mvista.com>
On Wed, 18 Dec 2002, Jun Sun wrote:
> > call to your dispatch_i8259_irq() C function. This can still be done with
> > a trivial wrapper like:
> >
> > asmlinkage void foo_dispatch_i8259_irq(struct pt_regs *regs)
> > {
> > do_IRQ(poll_8259A_irq(), regs);
> > }
> >
>
> This is essentially the same as adding dispatch_i8259_irq() to i8259.c file,
> which in turn calls an inline function as its function body.
It's not the same (assuming you'd use a separate file as not all
platforms need dispatch_i8259_irq()) as for other uses you may need
slightly different duplicates.
> Unless there is obvious another usage of poll_8259A_irq(), the inline function
> might as well be not inlined.
You lose several cycles for stack frame handling and the extraneous call
itself then.
> There is also a style issue. Dispatching an interrupt is really part of
> hw_interrupt_type structure. You should implement it in the same file as the
Not at all. The hw_interrupt_type structure is about handling (or
receiving) interrupts. The code we are talking about is about dispatching
(or sending) interrupts, which is sometimes done by hardware (e.g.
probably always for ia32). These activities are opposite to each other.
> rest functions. However, if anybody feels it is not optimized enough they are
> always free to lump all IRQ dispatching code together in one place, probably even
> in assembly code.
Within sane code we keep dispatchers separate from handlers and that
makes a lot of sense. Not only they are logically separated, but often
there are multiple unrelated handlers, e.g. three for most of DECstations,
and there is always a single dispatcher, i.e. the interrupt exception
handler. Also dispatchers are platform-specific, depending on the wiring,
desired priorities, etc., while handlers are generic, depending on an
interrupt controller chip only.
> I also disagree to have a header file with only one function declaration, but I
> agree there is orthognal issue, mostly a maintenance issue. So if Ralf is ok with that,
> I won't bitching about it.
It's better to have a self-contained header for a single declaration than
a single header collecting various weakly related junk -- see
<linux/sched.h> (and keep a barf bag handy -- you have been warned).
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re:hanging system
From: Orion Poplawski @ 2002-12-18 19:33 UTC (permalink / raw)
To: Manish Lachwani
Cc: ''scott@thomasons.org ' ',
''Alan Cox ' ',
''Linux Kernel Mailing List ' '
In-Reply-To: <233C89823A37714D95B1A891DE3BCE5202AB1B32@xch-a.win.zambeel.com>
Manish Lachwani wrote:
> I had found problems when using burnk6 on the CPUs. After running
> burnk6 for severl hrs, the CPUs used to get underclocked on bootup. I
> had also noticed occasional hangs on such CPUs
>
Well, burnK7 crashes this system pretty easily (few minutes). I also
get "254" error codes from it which apparently indicate an
"integer/memory error".
I've been trying to run "sensors" (from lm_sensors) to see if I can see
and voltage or temp issues while burnK7 is running, but I'm skeptical
that the temp readings are correct as they aren't moving much.
- Orion
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Larry McVoy @ 2002-12-18 19:33 UTC (permalink / raw)
To: Alan Cox
Cc: Larry McVoy, Linus Torvalds, Dave Jones, Horst von Brand,
linux-kernel, Andrew Morton
In-Reply-To: <200212181930.gBIJUmg13378@devserv.devel.redhat.com>
On Wed, Dec 18, 2002 at 02:30:48PM -0500, Alan Cox wrote:
> We've got one - its called linux-kernel.
Huh? That's like saying "we don't need a bug database, we have a mailing
list". That's patently wrong and so is your statement. If you want
reviews you need some place to store them. A mailing list isn't storage.
You'll do it however you want of course, but you are being stupid about it.
Why is that?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Alan Cox @ 2002-12-18 19:30 UTC (permalink / raw)
To: Larry McVoy
Cc: Alan Cox, Linus Torvalds, Dave Jones, Horst von Brand,
linux-kernel, Andrew Morton
In-Reply-To: <20021218112351.H7976@work.bitmover.com>
We've got one - its called linux-kernel.
Alan
^ permalink raw reply
* RE: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 seriescards
From: Neulinger, Nathan @ 2002-12-18 19:30 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
I gave it to Adam Radford and am talking to him directly on this now.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Wednesday, December 18, 2002 2:08 PM
> To: Neulinger, Nathan
> Cc: Linux Kernel Mailing List; Uetrecht, Daniel J.
> Subject: Re: 3ware driver in 2.4.x and 2.5.x not compatible
> with 6x00 seriescards
>
>
> On Wed, 2002-12-18 at 18:10, Nathan Neulinger wrote:
> > According to 3Ware, the driver in the 2.4.x and (I assume)
> 2.5.x is no
> > longer compatible with the 6xxx series cards.
>
> Please give the name of your 3ware contact so someone
> competent in 3ware
> so they can be 're-educated'
>
> I use the new driver with an old card, it works.
>
>
^ permalink raw reply
* Re: ALSA update
From: Greg KH @ 2002-12-18 19:27 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.33.0212182013070.550-100000@pnote.perex-int.cz>
On Wed, Dec 18, 2002 at 08:17:55PM +0100, Jaroslav Kysela wrote:
>
> Not much. We have 9 #ifdef's and all trying to resolve the conflicts with
> new function prototypes which is difficult to replace with defines or
> inline functions. Perhaps, you'll have an idea to solve this problem.
Short of keeping a 2.4 version and a 2.5/2.6 version, no, I do not have
any ideas, sorry. The USB core has changed a lot between those two
trees, as you know.
> For us, it's very important to have only one code base for all kernels,
> but on the other hand, we're trying to leave the 2.2/2.4 kernel code
> specific parts separate in our CVS repository if possible.
Then you might want to leave the OLD_USB stuff out of the 2.5 kernel :)
thanks,
greg k-h
^ permalink raw reply
* Re: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 series cards
From: Alan Cox @ 2002-12-18 20:08 UTC (permalink / raw)
To: Nathan Neulinger; +Cc: Linux Kernel Mailing List, uetrecht
In-Reply-To: <20021218181052.GA26465@umr.edu>
On Wed, 2002-12-18 at 18:10, Nathan Neulinger wrote:
> According to 3Ware, the driver in the 2.4.x and (I assume) 2.5.x is no
> longer compatible with the 6xxx series cards.
Please give the name of your 3ware contact so someone competent in 3ware
so they can be 're-educated'
I use the new driver with an old card, it works.
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Larry McVoy @ 2002-12-18 19:23 UTC (permalink / raw)
To: Alan Cox
Cc: Linus Torvalds, Dave Jones, Horst von Brand, linux-kernel,
Andrew Morton
In-Reply-To: <200212181908.gBIJ82M03155@devserv.devel.redhat.com>
Make it async. So anyone can review stuff and record their feelings in a
centralized place. We have a spare machine set up, kernel.bkbits.net,
that could be used as a dumping grounds for patches and reviews if
master.kernel.org is too locked down.
If you force the review process into a "push" model where patches are
sent to someone, then you are stuck waiting for them to review it and
it may or may not happen. Do the reviews in a centralized place where
everyone can see them and add their own comments.
On Wed, Dec 18, 2002 at 02:08:02PM -0500, Alan Cox wrote:
> > And I think it could work for the kernel too, especially the stable
> > releases and for the process of getting there. I just don't really know
> > how to set it up well.
>
> A start might be
>
> 1. Ack large patches you don't want with "Not for 2.6" instead
> of ignoring them. I'm bored of seeing the 18th resend of
> this and that wildly bogus patch.
>
> Then people know the status
>
> 2. Apply patches only after they have been approved by the maintainer
> of that code area.
>
> Where it is core code run it past Andrew, Al and other people
> with extremely good taste.
>
> 3. Anything which changes core stuff and needs new tools, setup
> etc please just say NO to for now. Modules was a mistake (hindsight
> I grant is a great thing), but its done. We don't want any more
>
>
> 4. Violate 1-3 when appropriate as always, but preferably not to
> often and after consulting the good taste department 8)
>
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* flashing a different bios-- is it safe?
From: James D Strandboge @ 2002-12-18 19:14 UTC (permalink / raw)
To: Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
I have a dell inspiron 8200, which has a bios that sort of works with
acpi, but will sometimes crash (see previous emails). I have looked at
my dsdt, and it is extraordinarily cryptic.
Today, I was googling for information about all of this, and came across
somebody flashing their insprion 8200 bios with the bios for the dell
latitude c840. This person was doing this to be able to use the port
replicator properly, and was running windows. He reported success and
no problems. This seems like a crazy thing to do-- is it safe? I
figured I may have to flash back to the old bios, but was worried that
this might break something permanently?
Thanks,
Jamie Strandboge
--
Email: jstrand1-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org
GPG/PGP ID: 26384A3A
Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: ALSA update
From: Jaroslav Kysela @ 2002-12-18 19:17 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021218182135.GD31197@kroah.com>
On Wed, 18 Dec 2002, Greg KH wrote:
> > ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, perex@suse.cz
>
> <snip>
>
> > diff -Nru a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c
> > --- a/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> > +++ b/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> > @@ -526,7 +526,11 @@
> > /*
> > * complete callback from data urb
> > */
> > +#ifndef OLD_USB
> > static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
> > +#else
> > +static void snd_complete_urb(struct urb *urb)
> > +#endif
> > {
> > snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> > snd_usb_substream_t *subs = ctx->subs;
> > @@ -551,7 +555,11 @@
> > /*
> > * complete callback from sync urb
> > */
> > +#ifndef OLD_USB
> > static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs)
> > +#else
> > +static void snd_complete_sync_urb(struct urb *urb)
> > +#endif
> > {
> > snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> > snd_usb_substream_t *subs = ctx->subs;
> > @@ -583,6 +591,9 @@
>
> Ick, you're kidding me, right? Why do this? Are you trying to keep a
> common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend
> it, as the code will be sprinkled with these ifdef's...
Not much. We have 9 #ifdef's and all trying to resolve the conflicts with
new function prototypes which is difficult to replace with defines or
inline functions. Perhaps, you'll have an idea to solve this problem.
For us, it's very important to have only one code base for all kernels,
but on the other hand, we're trying to leave the 2.2/2.4 kernel code
specific parts separate in our CVS repository if possible.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
^ permalink raw reply
* PVCs on X.25?
From: Ricardo Dias Cassali @ 2002-12-18 19:12 UTC (permalink / raw)
To: linux-x25
In-Reply-To: <008a01c29f7e$4d02ccc0$f70127d5@britannic>
Hi,
I'm using the Generic HDLC layer, with X.25 protocol support enabled,
and my intention is to run IP over X.25.
Is there a way to configure PVCs in this case?
Thanks in advance,
Ricardo Cassali.
^ permalink raw reply
* Re: Multithreaded coredump patch where?
From: mgross @ 2002-12-18 16:19 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Roberto Fichera, linux-kernel
In-Reply-To: <1040127295.10437.5.camel@laptop.fenrus.com>
On Tuesday 17 December 2002 04:14 am, Arjan van de Ven wrote:
> On Mon, 2002-12-16 at 22:21, mgross wrote:
> > I don't know if there is any plan to back port Ingo's version of this
> > feature to 2.4.x
>
> the current Red Hat Rawhide kernels have an attempt for a backport but
> it's not fully working right yet unfortionatly
Is this because you are doing both the NPTL kernel support and the
multi-threaded core dump in a combined back port making the effort more
complex?
What types of issues are you seeing with the back port?
I'm just wondering. These are cool features.
--mgross
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Andrew Morton @ 2002-12-18 19:12 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linus Torvalds, LKML
In-Reply-To: <20021218154023.29726d09.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
>
> Hi Linus, Andrew,
>
> On Tue, 17 Dec 2002 20:07:53 -0800 (PST) Linus Torvalds <torvalds@transmeta.com> wrote:
> >
> > Btw, on another tangent - Andrew Morton reports that APM is unhappy about
> > the fact that the fast system call stuff required us to move the segments
> > around a bit. That's probably because the APM code has the old APM segment
> > numbers hardcoded somewhere, but I don't see where (I certainly knew about
> > the segment number issue, and tried to update the cases I saw).
>
> I looked at this yesterday and decided that it was OK as well.
>
> > Debugging help would be appreciated, especially from somebody who knows
> > the APM code.
>
> It would help to know what "unhappy" means :-)
>
> Does the following fix it for you? Untested, assumes cache lines are 32
> bytes.
It does fix the apmd oops, and APM works fine.
Here's the patch again. (But what happens if cachelines are not 32 bytes?)
--- 25/include/asm-i386/segment.h~sfr Wed Dec 18 10:54:07 2002
+++ 25-akpm/include/asm-i386/segment.h Wed Dec 18 10:54:07 2002
@@ -65,9 +65,9 @@
#define GDT_ENTRY_APMBIOS_BASE (GDT_ENTRY_KERNEL_BASE + 11)
/*
- * The GDT has 23 entries but we pad it to cacheline boundary:
+ * The GDT has 25 entries but we pad it to cacheline boundary:
*/
-#define GDT_ENTRIES 24
+#define GDT_ENTRIES 28
#define GDT_SIZE (GDT_ENTRIES * 8)
_
^ permalink raw reply
* Re: [Benchmark] AIM9 results
From: Nikita Danilov @ 2002-12-18 19:10 UTC (permalink / raw)
To: Cliff White
Cc: Hans Reiser, Andrew Morton, Paolo Ciarrocchi, linux-kernel,
Chris Mason
In-Reply-To: <200212181847.gBIIlhO26530@mail.osdl.org>
Cliff White writes:
> > Andrew Morton wrote:
> >
> > >Andrew Morton wrote:
> > >
> > >
> > >>Hans Reiser wrote:
> > >>
> > >>
> > >>>Andrew and Chris, are these changes in performance definitely due to VM
> > >>>changes (and not some difference I am not thinking of between 2.5 and
> > >>>2.4 reiserfs code)?
> > >>>
> > >>>
> > >>>
> > >>aim9 is just doing
> > >>
> > >> for (lots)
> > >> close(creat(filename))
> > >>
> > >>
> > > unlink(filename); /* of course */
> > >
> > >
> > >
> > >
> > Oh, commercial fs vendors must really love tuning for this benchmark....
> > sigh....
> >
> Ya, we think the AIM stuff is getting a little old. The basic idea is fine, but
> many of the tests do _very little work. We (OSDL) would like to re-do
> AIM9+7 and make it more useful. We'd love to have some input from everyone....
> For example, how big a file should we create for a real creat() test ?
Probably it should be variable. You may take a look at the way "mongo"
script (http://www.namesys.com/benchmarks/mongo.tar.gz) used to
benchmark reiserfs calculates size of file
(reiser_fract_tree.c:determine_size() function). Hmm, I remember putting
long comment for this function, but now it is gone...
> cliffw
>
> > Hans
> >
Nikita.
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Alan Cox @ 2002-12-18 19:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Jones, Horst von Brand, linux-kernel, Alan Cox,
Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0212180936550.2891-100000@home.transmeta.com>
> And I think it could work for the kernel too, especially the stable
> releases and for the process of getting there. I just don't really know
> how to set it up well.
A start might be
1. Ack large patches you don't want with "Not for 2.6" instead
of ignoring them. I'm bored of seeing the 18th resend of
this and that wildly bogus patch.
Then people know the status
2. Apply patches only after they have been approved by the maintainer
of that code area.
Where it is core code run it past Andrew, Al and other people
with extremely good taste.
3. Anything which changes core stuff and needs new tools, setup
etc please just say NO to for now. Modules was a mistake (hindsight
I grant is a great thing), but its done. We don't want any more
4. Violate 1-3 when appropriate as always, but preferably not to
often and after consulting the good taste department 8)
Alan
^ permalink raw reply
* Re: Multithreaded coredump patch where?
From: mgross @ 2002-12-18 16:13 UTC (permalink / raw)
To: Roberto Fichera; +Cc: linux-kernel
In-Reply-To: <5.2.0.9.0.20021217105617.00aa31e0@mail.isolaweb.it>
On Tuesday 17 December 2002 03:05 am, Roberto Fichera wrote:
> >I haven't rebased the patches I posted back in June for a while now.
> >
> >Attached is the patch I posted for the 2.4.18 vanilla kernel. Its a bit
> >controversial, but it seems to work for a number of folks. Let me know if
> >you have any troubles re-basing it.
>
> Only one hunk failed on include/asm-ia64/elf.h but fixed by hand.
> Why do you say a bit controversial ? One difference that I have
> notice is in coredump size after your patch. However seem to be
> working well for now. I'll try later on a SMP machine.
There are 2 issues with this implementation that will likely not effect you.
First, when dumping core of MT applications with LOTS of threads the pthread
library signals all the threads in the application to exit. Sometimes
the process that is dumping core fails to suspend other threads in the
application before some exit. The result of this is that for such
applications you will not see them in the core file.
You have to work at it to see this failure. The way I reproduce this is to
run a test application with about 555 pthread threads in it and send it a
sig_quit. When I look at the core file wont have all 555 threads. SMP makes
this effect a bit more noticeable.
Ingo's design to fix this change the exit path for thread to wait for the
core file to get dumped before finishing the process clean up. I like this
approach, I just wish I thought of it ;)
Second, the controversial issue is in the way my design pauses the other
threads in the MT application. Its not semaphore lock safe. Although no
instance of the following failure has been seen, it is possible with new
kernel code.
If one of the processes in the MT application is currently holding semaphore
lock when the dumping process pauses it, AND the dumping process does any
blocking operation that could attempt to grab this same semaphore, THEN the
core dump will deadlock. Boom.
My patch is good for developers, pending the back port of Ingo's version.
Do let me know how it works out for you.
--mgross
^ permalink raw reply
* Re: [PATCH] (2.5;v3) move LOG_BUF_SIZE to header/config
From: Andrew Morton @ 2002-12-18 19:06 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: torvalds, linux-kernel
In-Reply-To: <Pine.LNX.4.33L2.0212181013470.21858-100000@dragon.pdx.osdl.net>
"Randy.Dunlap" wrote:
>
> Linus,
>
> Patch applies to 2.5.52-bk3.
>
> This makes LOG_BUF_LEN (actually its shift value) a configurable
> parameter. It does this by adding a general/common config file
> that can use processor-related dependencies. This new Kconfig file
> is located in linux/kernel/ and is included at the end of each
> arch/*/Kconfig file.
>
> Modified to address comments from Christoph Hellwig, James Cloos,
> and Andrew Morton, who likes it.
>
The reason I like it is that it adds $TOPDIR/kernel/Kconfig. Several
times I've been confronted with the need to put exactly the same thing
into each and every arch/<arch>/Kconfig. There doesn't seem to be a
single all-architectures "general stuff" place at present.
^ permalink raw reply
* Horrible drive performance under concurrent i/o jobs (dlh problem?)
From: Torben Frey @ 2002-12-18 19:06 UTC (permalink / raw)
To: linux-kernel
Hi list readers (and hopefully writers),
after getting crazy with our main server in the company for over a week
now, this list is possibly my last help - I am no kernel programmer but
suscpect it to be a kernel problem. Reading through the list did not
help me (although I already thought so, see below).
We are running a 3ware Escalade 7850 Raid controller with 7 IBM Deskstar
GXP 180 disks in Raid 5 mode, so it builds a 1.11TB disk.
There's one partition on it, /dev/sda1, formatted with Reiserfs format
3.6. The Board is an MSI 6501 (K7D Master) with 1GB RAM but only one
processor.
We were running the Raid smoothly while there was not much I/O - but
when we tried to produce large amounts of data last week, read and write
performance went down to inacceptable low rates. The load of the machine
went high up to 8,9,10... and every disk access stopped processes from
responding for a few seconds (nedit, ls). An "rm" of many small files
made the machine not react to "reboot" anymore, I had to reset it.
So copied everything away to a software raid and tried all the disk
tuning stuff (min-, max-readahead, bdflush, elvtune). Nothing helped.
Last Sunday I then found a hint about a bug introduced in kernel
2.4.19-pre6 which could be fixed using a "dlh", disk latency hack - or
going back to 2.4.18. Last is what I did ( from 2.4.20 )
It seemed to help in a way that I could copy about 350GB back to the
RAID in about 3-4 hrs overnight. So I THOUGHT everything would be fine.
Since Tuesday morning my collegues are trying to produce large amounts
of data again - and every concurrent I/O operation blocks all the
others. We cannot work with that.
When I am working all alone on the disk creating a 1 GB file by
time dd if=/dev/zero of=testfile bs=1G count=1
results in real times from 14 seconds when I am very lucky up to 4
minutes usually.
Watching vmstat 1 shows me that "bo" drops quickly down from rates in
the 10 or 20 thousands to low rates of about 2 or 3 thousands when the
runs take so long.
Can anyone of you please tell me how can I find out if this is a kernel
problem or a hardware 3ware-device problem? Is there a way to see the
difference? Or could it come from running an SMP kernel although I have
only one CPU in my board?
I would be very happy about every answer, really!
Torben
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Mark Mielke @ 2002-12-18 19:12 UTC (permalink / raw)
To: Horst von Brand; +Cc: linux-kernel
In-Reply-To: <200212181410.gBIEAod6027746@pincoya.inf.utfsm.cl>
On Wed, Dec 18, 2002 at 11:10:50AM -0300, Horst von Brand wrote:
> Sean Neakums <sneakums@zork.net> said:
> > How are system calls a new feature? Or is optimizing an existing
> > feature not allowed by your definition of "feature freeze"?
> This "optimizing" is very much userspace-visible, and a radical change in
> an interface this fundamental counts as a new feature in my book.
Since operating systems like WIN32 are at least published to take
advantage of SYSENTER, it may not be in Linux's interest to
purposefully use a slower interface until 2.8 (how long will that be
until people can use?). The last thing I want to read about in a
technical journal is how WIN32 has lower system call overhead than
Linux on IA-32 architectures. That might just be selfish of me for
the Linux community... :-)
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
^ 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.