* Re: Intel P6 vs P7 system call performance
From: dean gaudet @ 2002-12-17 6:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162204300.1800-100000@home.transmeta.com>
On Mon, 16 Dec 2002, Linus Torvalds wrote:
> It's not as good as a pure user-mode solution using tsc could be, but
> we've seen the kinds of complexities that has with multi-CPU systems, and
> they are so painful that I suspect the sysenter approach is a lot more
> palatable even if it doesn't allow for the absolute best theoretical
> numbers.
don't many of the multi-CPU problems with tsc go away because you've got a
per-cpu physical page for the vsyscall?
i.e. per-cpu tsc epoch and scaling can be set on that page.
the only trouble i know of is what happens when an interrupt occurs and
the task is rescheduled on another cpu... in theory you could test %eip
against 0xfffffxxx and "rollback" (or complete) any incomplete
gettimeofday call prior to saving a task's state. but i bet that test is
undesirable on all interrupt paths.
-dean
^ permalink raw reply
* Re: [PATCH] move LOG_BUF_SIZE to header file
From: James H. Cloos Jr. @ 2002-12-17 6:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Randy.Dunlap, Andrew Morton
In-Reply-To: <Pine.LNX.4.33L2.0212121517300.19827-100000@dragon.pdx.osdl.net>
I was just looking at doing that.
I'd suggest including CONFIG_CRYPTO_TEST in the default size
determination, and allowing both smaller sizes (for low ram
applications, such as embedded systems) and larger ones.
With all of the crypto =y, the test wipes everything before ACPI out
of the buffer before syslogd gets to start and log the buffer to disk.
Even with a 64k buffer.
-JimC
^ permalink raw reply
* lk maintainers
From: Denis Vlasenko @ 2002-12-17 11:17 UTC (permalink / raw)
To: linux-kernel
This document is mailed to lkml regularly and will be modified
whenever new victim wishes to be listed in it or someone can
no longer devote his time to maintainer work.
If you want your entry added/updated/removed, contact me.
BTW, requests to move your entry to the top of the list
without actually changing the text are fine too: that
will indicate that entry is not outdated, so don't be shy ;-)
--
vda
------- cut here ------ cut here ------ cut here ------ cut here ------
So, you are new to Linux kernel hacking and want to submit a kernel bug
report or a patch but don't know how to do it and _where_ to report it?
Preparing bug report:
=====================
*** Remember: bad/incomplete bug report ONLY wastes bandwidth! ***
How To Ask Questions The Smart Way:
http://www.tuxedo.org/~esr/faqs/smart-questions.html
Anybody who has written software for public use will
probably have received at least one bad bug report.
Reports that say nothing ("It doesn't work!");
reports that make no sense; reports that don't give
enough information; reports that give wrong information.
How to Report Bugs Effectively:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Before asking a technical question by email, or in
a newsgroup, or on a website chat board, do the following:
* Try to find an answer by searching the Web.
* Try to find an answer by reading the manual.
* Try to find an answer by reading a FAQ.
* Try to find an answer by inspection or experimentation.
* Try to find an answer by reading the source code.
Compile problems: report GCC output and result of
"grep '^CONFIG_' .config"
Oops: decode it with ksymoops (or use 2.5 with kksymoops enabled ;).
Unkillable process: Alt-SysRq-T and ksymoops relevant part.
Yes it means you should have ksymoops installed and tested,
Sending bug report/patch:
=========================
* Some device drivers have active developers, try to contact them first.
* Otherwise find a subsystem maintainer to which your report pertains
and send report to his address.
* Small fixes and device driver updates are best directed to subsystem
maintainers and "small bits" integrators.
* It never hurts to CC: Linux kernel mailing list, but without specific
maintainer address in To: field there is high probability that your
patch won't be noticed. You have been warned.
* Do not send it to all addresses at once! This will annoy lots of
people
and isn't useful at all. It's a spam.
* Do NOT send small fixes to Linus, he just can't handle _everything_.
He will eventually receive it from maintainers/integrators, send it
their way.
* If your patch is something big and new, announce it on lkml and try
to attract testers. After it has been tested and discussed, you can
expect Linus to consider inclusion in mainline.
Current Linux kernel people
Note that this list is sorted in reversed date order, most recent
entries first. This means than entries at bottom can be outdated :-(
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Post anything related to Linux kernel here, but nothing else :-)
Andrew Morton <akpm@digeo.com> [10 dec 2002]
- VM
- The "data" part of the VFS: pagecache, buffer layer, etc.
- memory management
- ext2 and ext3
- 3c59x.c
- direct-IO
James Simmons <jsimmons@infradead.org> [28 Nov 2002]
Console and framebuffer subsystems.
I also play around with the input layer.
Petko Manolov <petkan@users.sourceforge.net> [27 nov 2002]
pegasus and rtl8150 usb-ethernet drivers maintainer.
Interested in any bugs or new devices related to those drivers.
string-486.h code maintainer.
Greg Ungerer <gerg@snapgear.com> [14 nov 2002]
uClinux (MMU-less support) maintainer. I'll take antyhing
specifically related to MMU-less support or any of the
MMU-less architecture branches (m68knommu, v850, etc).
I would highly recommend sending to uclinux-dev@uclinux.org
mailing list as well.
Andre Hedrick <andre@linux-ide.org> [02 oct 2002]
ATA/ATAPI Storage Architect [2.0,2.2,2.4,2.5]
HBA interface developer
Serial ATA Architect [future release]
Voting NCITS member AT-Attachment Committee
Jeff Garzik <jgarzik@mandrakesoft.com> [24 sep 2002]
I am the network-card-drivers guy (8139 for instance).
CC me and Andrew Morton <akpm@digeo.com> on network driver patches.
Jan-Benedict Glaw <jbglaw@lug-owl.de> [18 sep 2002]
I'm responsible for Alpha's srm_env driver, providing access to
SRM's firmware variables.
Stuart MacDonald <stuartm@connecttech.com> [13 sep 2002]
Connect Tech's linux kernel guy. Currently includes hacking on
drivers/char/serial.c (Blue Heat, Xtreme, Dflex) and maintaining
drivers/usb/serial/whiteheat.c (WhiteHEAT)
Vojtech Pavlik <vojtech@ucw.cz> [13 sep 2002]
Feel free to send me bug reports and patches to input device drivers
(drivers/input/*, drivers/char/joystick/*)
I also want to receive bug reports and patches for following
USB drivers: printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
All other (not in the list) USB driver changes should go to USB
maintainer (hopefully there is one listed here :-).
Also CC me if you are posting VIA IDE driver related message
(although I am not IDE subsystem maintainer).
Robert Love <rml@tech9.net> [12 sep 2002]
Preemptible kernel maintainer.
I am also interesting in anything related to scheduling or locking
primitives.
Jan Kara <jack@suse.cz> [22 aug 2002]
quota subsystem maintainer
Paul Larson <plars@linuxtestproject.org> [20 aug 2002]
I'm a maintainer for the Linux Test Project and it would be nice
if people knew to send their test programs, etc. to me. I see
a lot of them flying around on lkml and try to catch them when
I can, but it's a lot to keep up with. It would be even better
if people just knew to send them our way so we could clean
them up and put them in LTP for regression testing.
Dave Engebretsen <engebret@vnet.ibm.com> [15 aug 2002]
PPC64 architecture maintainer. Please send PPC64 patches to me
and our mailing list at <linuxppc64-dev@lists.linuxppc.org>
Ingo Molnar <mingo@elte.hu> [30 jul 2002]
Ingo wrote the new scheduler for 2.5.
Ralf Baechle <ralf@uni-koblenz.de> [30 jul 2002]
I am maintainer of the AX.25 code
Victor Yodaiken <yodaiken@fsmlabs.com> [30 jul 2002]
RTLinux patches, updates, contributions, drivers.
Please send first to the list: rtl@rtlinux.org
Pavel Machek <pavel@ucw.cz> [27 jul 2002]
I am network block device maintainer. Visit http://nbd.sf.net.
(see Steven Whitehouse <steve@gw.chygwyn.com> entry)
I am working on software suspend.
William Irwin <wli@holomorphy.com> [02 jul 2002]
Send bug reports and/or feature requests related to many tasks,
rmap, space consumption, or allocators to me. I'm involved in
* rmap
* memory allocators
* reducing space consumed by data structures (e.g. struct page)
* issues arising in workloads with many tasks
* kernel janitoring
See also:
Rik van Riel <riel@surriel.com>
Andrea Arcangeli <andrea@suse.de>
Martin Bligh <Martin.Bligh@us.ibm.com>
Andrew Morton <akpm@digeo.com>
Dave Jones <davej@suse.de> [23 apr 2002]
I collect various bits and pieces for inclusion in 2.5,
especially small and trivial ones and driver updates.
I'll feed them to Linus when (and if) they
are proved to be worthy.
Andrea Arcangeli <andrea@suse.de> [28 mar 2002]
Send VM related bug reports and patches to me.
I'm especially interested in VM issues with:
* lots of RAM and CPUs
* NUMA
* heavy swap scenarios
* performance of I/O intensive workloads (in particular
with lots of async buffer flushing involved)
See also Martin J. Bligh <Martin.Bligh@us.ibm.com> entry
Mail also:
Arjan van de Ven <arjanv@redhat.com>
Martin J. Bligh <Martin.Bligh@us.ibm.com> [28 mar 2002]
I'm interested in VM issues with lots (>4G for i386)
of RAM, lots of CPUs, NUMA
Steven Whitehouse <steve@chygwyn.com> [27 mar 2002]
I am the Linux DECnet network stack maintainer
Visit http://www.chygwyn.com/decnet/
Arnaldo Carvalho de Melo <acme@conectiva.com.br> [26 mar 2002]
IPX, 802.2 LLC, NetBEUI, http://kerneljanitors.org,
cyclom2x sync card driver
John Cagle <jcagle@kernel.org> [19 mar 2002]
The current maintainer of devices.txt, the list of
assigned device numbers for LANANA. Consult the web
site (www.lanana.org) for instructions on submitting
requests for new device numbers. Send all device
related email to <device@lanana.org>.
Tigran Aivazian <tigran@veritas.com>
I am author and maintainer of BFS filesystem and IA32
microcode update driver.
Rogier Wolff <R.E.Wolff@BitWizard.nl> [12 mar 2002]
I do "specialix serial ports":
drivers/char/specialix.c (IO8+)
drivers/char/sx.c (SX, SI, SIO)
drivers/char/rio/*.c (RIO)
Martin Dalecki <martin@dalecki.de> [11 mar 2002]
IDE subsystem maintainer for 2.5
(mail Vojtech Pavlik <vojtech@suse.cz> too)
Ed Vance <serial24@macrolink.com> [05 mar 2002]
Maintainer for the generic serial driver, serial.c,
for 2.2 and 2.4 kernels. Please post patches to
linux-serial@vger.kernel.org for tested bug
fixes or to add support for a new serial device.
Limited to time available. If I have not responded
in a week, yell at serial24@macrolink.com
netfilter/iptables <netfilter-devel@lists.samba.org> [23 feb 2002]
Please report all netfilter/iptables related problems
to this mailinglist, where all netfilter developers are present.
See also http://www.netfilter.org/contact.html
Hans Reiser <reiser@namesys.com> [16 feb 2002]
Send me all reiserfs related patches with a cc to
reiserfs-dev@namesys.com, send bug reports to
reiserfs-dev@namesys.com, send paid support requests to
support@namesys.com after going to www.namesys.com/support.html
to pay, send discussions (not bug reports unless they are
interesting to most persons) to reiserfs-list@namesys.com.
If we sit on your patch for a week without responding,
yell at us, we deserve it. Look at our web page
at www.namesys.com for more about sending us code,
working with us, and our patch submission and tracking system.
Paul Bristow <paul@paulbristow.net> [16 feb 2002]
I am an ide-floppy driver maintainer
(ATAPI ZIP, LS-120/240 Superdisk, Clik! drives).
Mike Phillips <phillim2@comcast.net> [15 feb 2002]
Token ring subsystem and drivers.
Anton Altaparmakov <aia21@cam.ac.uk> [15 feb 2002]
I am the NTFS guy.
https://bugzilla.redhat.com/bugzilla [14 feb 2002]
Reports of problems with the Red Hat shipped kernels.
Alan Cox <alan@lxorguk.ukuu.org.uk> [14 feb 2002]
Linux 2.2 maintainer (maintenance fixes only).
Collator of patches for unmaintained things in 2.2/2.4.
Maintainer of the 2.4-ac (2.4 plus stuff being tested) tree.
I2O, sound, 3c501 maintainer for 2.2/2.4.
ALSA development <alsa-devel@alsa-project.org> [12 feb 2002]
Jaroslav Kysela <perex@perex.cz> [12 feb 2002]
Advanced Linux Sound Architecture
ALSA patches are available at
ftp://ftp.alsa-project.org/pub/kernel-patches/*
Neil Brown <neilb@cse.unsw.edu.au> [08 feb 2002]
I am interested in any issues with the code in:
NFS server (fs/nfsd/*)
software RAID (drivers/md/{md,raid,linear}*)
or related include files.
Maksim Krasnyanskiy <maxk@qualcomm.com> [08 feb 2002]
I'm author and maintainer of the Bluetooth subsystem
and Universal TUN/TAP device driver.
These days mostly working on Bluetooth stuff.
Rik van Riel <riel@conectiva.com.br> [07 feb 2002]
Send me VM related stuff, please CC to linux-mm@kvack.org
Geert Uytterhoeven <geert@linux-m68k.org> [07 feb 2002]
I work on the frame buffer subsystem, the m68k port (Amiga part),
and the PPC port (CHRP LongTrail part).
Unfortunately I barely have spare time to really work on these
things. My job is not Linux-related (so far :-). I can not
promise anything about my maintainership performance.
H. Peter Anvin <hpa@zytor.com> [07 feb 2002]
i386 boot and feature code, i386 boot protocol, autofs3,
compressed iso9660 (but I'll accept all iso9660-related
changes). kernel.org site manager; please contact me
for sponsorship-related issues.
kernel.org admins <ftpadmin@kernel.org> [07 feb 2002]
Kernel.org sysadmins. Contact us if you notice something breaks,
or if you want a change make sure you give us at least 1-2 weeks.
Please note that we got a lot of feature requests, a lot of
which conflict or simply aren't practical; we don't have time to
respond to all requests.
Greg KH <greg@kroah.com> [07 feb 2002]
I am USB and PCI Hotplug maintainer.
Trond Myklebust <trond.myklebust@fys.uio.no> [07 feb 2002]
I am NFS client maintainer.
Richard Gooch <rgooch@atnf.csiro.au> [07 feb 2002]
I maintain devfs. I want people to Cc: me when reporting devfs
problems, since I don't read all messages on linux-kernel.
Send devfs related patches to me directly, rather than
bypassing me and sending to Linus/Marcelo/Alan/Dave etc.
Russell King <rmk@arm.linux.org.uk> [06 feb 2002]
ARM architecture maintainer. Please send all ARM patches through
the patch system at http://www.arm.linux.org.uk/developer/patches/
New serial drivers maintainer for 2.5. Submit patches to
rmk+serial@arm.linux.org.uk
Petr Vandrovec <vandrove@vc.cvut.cz> [05 feb 2002]
ncpfs filesystem, matrox framebuffer driver, problems related
to VMware - in all of 2.2.x, 2.4.x and 2.5.x.
Reiserfs developers list <reiserfs-dev@namesys.com> [05 feb 2002]
Send all reiserfs-related stuff here including but not limited to bug
reports, fixes, suggestions.
Oleg Drokin <green@linuxhacker.ru> [05 feb 2002]
SA11x0 USB-ethernet and SA11x0 watchdog are mine.
======= These entries are suggested by lkml folks ========
Ralf Baechle <ralf@gnu.org> [27 mar 2002]
I am mips/mips64 maintainer.
David S. Miller <davem@redhat.com> [07 feb 2002]
I am Sparc64 and networking core maintainer.
======= These ones I made myself ========
======= I am waiting confirmation/correction from these people ========
Urban Widmark <urban@teststation.com> [13 feb 2002]
smbfs
video4linux list <video4linux-list@redhat.com> [12 feb 2002]
Gerd Knorr <kraxel@bytesex.org> [12 feb 2002]
video4linux
Tim Waugh <twaugh@redhat.com> [08 feb 2002]
> Who is maintaining the linux iomega stuff?
For 2.4.x, me (in theory). I don't have time for 2.5.x at the moment.
Alexander Viro <viro@math.psu.edu> [5 feb 2002]
I am NOT a fs subsystem maintainer. But I won't kill
you if you send me some generic fs bug reports and (hopefully) patches.
Eric S. Raymond <esr@thyrsus.com> [5 feb 2002]
Send kernel configuration bug reports and suggestions to me.
Also I'll be more than happy to accept help enties for kernel config
options (Configure.help).
GИrard Roudier <groudier@free.fr> [5 feb 2002]
I am SCSI guy.
Jens Axboe <axboe@suse.de> [5 feb 2002]
I am block device subsystem maintainer.
Linus Torvalds <torvalds@transmeta.com> [5 feb 2002]
Do not send anything to me unless it is for 2.5, well tested,
discussed on lkml and is used by significant number of people.
In general it is a bad idea to send me small fixes and driver
updates, send them to subsystem maintainers and/or
"small stuff" integrator (currently Dave Jones <davej@suse.de>,
see his entry). Sorry, I can't do everything.
Marcelo Tosatti <marcelo@conectiva.com.br> [5 feb 2002]
Do not send anything to me unless it is for 2.4 and well tested.
If you are sending me small fixes and driver updates, send
a copy to subsystem maintainers and/or "small stuff" integrators:
- Alan Cox <alan@lxorguk.ukuu.org.uk>,
- Rusty Russell <trivial@rustcorp.com.au>.
Rusty Russell <rusty@rustcorp.com.au> [5 feb 2002]
> Here are some cleanups of whitespace in .....
Want me to add this to the trivial patch collection for tracking?
If so just send (or cc:) it to trivial@rustcorp.com.au.
^ permalink raw reply
* My cpu fuzzy problem was due to XMMS
From: Xavier LaRue @ 2002-12-17 6:16 UTC (permalink / raw)
To: linux-kernel
:).. I just found it out :)
But now my real problem.. That probably slow down considerably my box,
How to make my L2 cache reconized
my dmesg is hosted here http://paxl.no-ip.org/~paxl/dmesg.txt
Please anyone help me :)
Xavier LaRue
^ permalink raw reply
* Re: HT Benchmarks (was: /proc/cpuinfo and hyperthreading)
From: Denis Vlasenko @ 2002-12-17 11:03 UTC (permalink / raw)
To: J.A. Magallon, Scott Robert Ladd; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021216232755.GA3750@werewolf.able.es>
On 16 December 2002 21:27, J.A. Magallon wrote:
> On 2002.12.17 Scott Robert Ladd wrote:
> [...]
>
> From what I can see, HT provides a 0-15% increase in performance,
> depending
>
> >heavily on the type of code being run. In other words, HT helps, but
> > it is *no* substitute for true multiple processors. And it is ONLY
> > of value when an SMP kernel is in use.
>
> What I don't like is that Intel sells it like the best thing since
> sliced bread, and get a money for it, see the price of Xeons compared
> to normal P4s...
What did you expect? They are making processors for money, and have
to push the sales.
As to HT, it's definitely a good thing. Multiple CPUs on a chip is
a logical step. HT in P4 is rather weak, but future processors will
likely have more advanced cores.
I never heard about HT from AMD camp. I'm curious what they do. ;)
--
vda
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: GrandMasterLee @ 2002-12-17 6:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162204300.1800-100000@home.transmeta.com>
On Tue, 2002-12-17 at 00:09, Linus Torvalds wrote:
> On Mon, 16 Dec 2002, Linus Torvalds wrote:
> >
> > On my P4 machine, a "getppid()" is 641 cycles with sysenter/sysexit, and
> > something like 1761 cycles with the old "int 0x80/iret" approach. That's a
> > noticeable improvement, but I have to say that I'm a bit disappointed in
> > the P4 still, it shouldn't be even that much.
>
> On a slightly more real system call (gettimeofday - which actually matters
> in real life) the difference is still visible, but less so - because the
> system call itself takes more of the time, and the kernel entry overhead
> is thus not as clear.
>
> For gettimeofday(), the results on my P4 are:
>
> sysenter: 1280.425844 cycles
> int/iret: 2415.698224 cycles
> 1135.272380 cycles diff
> factor 1.886637
>
> ie sysenter makes that system call almost twice as fast.
I'm curious, if this is one of the Dual P4's non-Xeon(say, 2.4 Ghz+?) or
if this is one of the Xeons? There seems to be some perceived disparity
between which performs how. I think the biggest difference on the Xeon's
is the stepping and the cache,(pipeline too?), but not too much else.
[...]
> Linus
>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 6:18 UTC (permalink / raw)
To: Dave Jones; +Cc: Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162204300.1800-100000@home.transmeta.com>
On Mon, 16 Dec 2002, Linus Torvalds wrote:
>
> For gettimeofday(), the results on my P4 are:
>
> sysenter: 1280.425844 cycles
> int/iret: 2415.698224 cycles
> 1135.272380 cycles diff
> factor 1.886637
>
> ie sysenter makes that system call almost twice as fast.
Final comparison for the evening: a PIII looks very different, since the
system call overhead is much smaller to begin with. On a PIII, the above
ends up looking like
gettimeofday() testing:
sysenter: 561.697236 cycles
int/iret: 686.170463 cycles
124.473227 cycles diff
factor 1.221602
ie the speedup is much less because the original int/iret numbers aren't
nearly as embarrassing as the P4 ones. It's still a win, though.
Linus
^ permalink raw reply
* [PATCH] move LOG_BUF_SIZE to header file
From: Randy.Dunlap @ 2002-12-17 6:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <3DF64369.81F288FE@digeo.com>
On Tue, 10 Dec 2002, Andrew Morton wrote:
| "Randy.Dunlap" wrote:
| >
| > I'd like to see LOG_BUF_LEN from kernel/printk.c moved to a header file
| > so that some non-kernel (kernel-mode) tools can know the value being
| > used (tools like kmsgdump or lkcd etc.).
| >
| > This patch moves LOG_BUF_LEN to include/linux/kernel.h .
| > Or it could go to a separate (new) header file...
| >
| > ...
| > -#if defined(CONFIG_X86_NUMAQ) || defined(CONFIG_IA64)
| > -#define LOG_BUF_LEN (65536)
| > -#elif defined(CONFIG_ARCH_S390)
| > -#define LOG_BUF_LEN (131072)
| > -#elif defined(CONFIG_SMP)
| > -#define LOG_BUF_LEN (32768)
| > -#else
| > -#define LOG_BUF_LEN (16384) /* This must be a power of two */
| > -#endif
| > -
| > -#define LOG_BUF_MASK (LOG_BUF_LEN-1)
|
| It's probably better to move all this gunk into the config
| system. Then your app can use CONFIG_LOG_BUF_LEN, too.
Hi, [after some delay]
I did think of that and agree that it makes some sense.
I don't really mind how it's done, so if that will help move along
the change, I'm for it.
I want to thank Roman Zippel for helping me thru this and with
enabling Kconfig with code to support this (that was already
in progress). This patch requires Kconfig changes in 2.5.52.
Here's what I have, tested with
make ARCH=<all 20 of them in succession> menuconfig
This puts the 'Kernel log buffer size' under Kernel hacking.
General Setup was too early for it since this needs processor
type/SMP info.
One other thing that I considered doing was using a common
Kconfig file for all 20 arch'es by adding a
source "kernel/Kconfig"
at the end of each <arch>/Kconfig file. This would provide
a common "General setup (more)" that could be used after most
config options are set instead of near the top of the menu.
Does that make sense to anybody?
More comments, feedback?
Thanks,
~Randy
patch_name: logbuf-2552b.patch
patch_version: 2002.12.16
author: Randy Dunlap <rddunlap@osdl.org>
description: change LOG_BUF_SIZE to a config option
product: linux
product_versions: 2.5.52
changelog:
URL:
requires: kconfig in 2.5.52
conflicts:
diffstat:
arch/alpha/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/cris/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/i386/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/ia64/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/m68k/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/m68knommu/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/mips/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/mips64/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/parisc/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/ppc/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/ppc64/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/s390/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/s390x/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/sh/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/sparc/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/sparc64/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/um/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/v850/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
arch/x86_64/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
kernel/printk.c | 34 ++++++++++++----------------------
21 files changed, 752 insertions(+), 22 deletions(-)
--- ./arch/i386/Kconfig%LOGBUF Sun Dec 15 18:07:47 2002
+++ ./arch/i386/Kconfig Sun Dec 15 20:45:09 2002
@@ -1573,6 +1573,43 @@
If you don't debug the kernel, you can say N, but we may not be able
to solve problems without frame pointers.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
config X86_EXTRA_IRQS
bool
depends on X86_LOCAL_APIC
--- ./kernel/printk.c%LOGBUF Sun Dec 15 18:08:24 2002
+++ ./kernel/printk.c Sun Dec 15 20:49:49 2002
@@ -30,17 +30,7 @@
#include <asm/uaccess.h>
-#if defined(CONFIG_X86_NUMAQ) || defined(CONFIG_IA64)
-#define LOG_BUF_LEN (65536)
-#elif defined(CONFIG_ARCH_S390)
-#define LOG_BUF_LEN (131072)
-#elif defined(CONFIG_SMP)
-#define LOG_BUF_LEN (32768)
-#else
-#define LOG_BUF_LEN (16384) /* This must be a power of two */
-#endif
-
-#define LOG_BUF_MASK (LOG_BUF_LEN-1)
+#define LOG_BUF_MASK (CONFIG_LOG_BUF_LEN-1)
#ifndef arch_consoles_callable
#define arch_consoles_callable() (1)
@@ -79,11 +69,11 @@
*/
static spinlock_t logbuf_lock = SPIN_LOCK_UNLOCKED;
-static char log_buf[LOG_BUF_LEN];
+static char log_buf[CONFIG_LOG_BUF_LEN];
#define LOG_BUF(idx) (log_buf[(idx) & LOG_BUF_MASK])
/*
- * The indices into log_buf are not constrained to LOG_BUF_LEN - they
+ * The indices into log_buf are not constrained to CONFIG_LOG_BUF_LEN - they
* must be masked before subscripting
*/
static unsigned long log_start; /* Index into log_buf: next char to be read by syslog() */
@@ -219,8 +209,8 @@
if (error)
goto out;
count = len;
- if (count > LOG_BUF_LEN)
- count = LOG_BUF_LEN;
+ if (count > CONFIG_LOG_BUF_LEN)
+ count = CONFIG_LOG_BUF_LEN;
spin_lock_irq(&logbuf_lock);
if (count > logged_chars)
count = logged_chars;
@@ -235,7 +225,7 @@
*/
for(i=0;i < count;i++) {
j = limit-1-i;
- if (j+LOG_BUF_LEN < log_end)
+ if (j+CONFIG_LOG_BUF_LEN < log_end)
break;
c = LOG_BUF(j);
spin_unlock_irq(&logbuf_lock);
@@ -321,7 +311,7 @@
if (msg_log_level < console_loglevel && console_drivers && start != end) {
if ((start & LOG_BUF_MASK) > (end & LOG_BUF_MASK)) {
/* wrapped write */
- __call_console_drivers(start & LOG_BUF_MASK, LOG_BUF_LEN);
+ __call_console_drivers(start & LOG_BUF_MASK, CONFIG_LOG_BUF_LEN);
__call_console_drivers(0, end & LOG_BUF_MASK);
} else {
__call_console_drivers(start, end);
@@ -384,11 +374,11 @@
{
LOG_BUF(log_end) = c;
log_end++;
- if (log_end - log_start > LOG_BUF_LEN)
- log_start = log_end - LOG_BUF_LEN;
- if (log_end - con_start > LOG_BUF_LEN)
- con_start = log_end - LOG_BUF_LEN;
- if (logged_chars < LOG_BUF_LEN)
+ if (log_end - log_start > CONFIG_LOG_BUF_LEN)
+ log_start = log_end - CONFIG_LOG_BUF_LEN;
+ if (log_end - con_start > CONFIG_LOG_BUF_LEN)
+ con_start = log_end - CONFIG_LOG_BUF_LEN;
+ if (logged_chars < CONFIG_LOG_BUF_LEN)
logged_chars++;
}
--- ./arch/m68k/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/m68k/Kconfig Mon Dec 16 21:07:31 2002
@@ -2338,6 +2338,43 @@
bool "Verbose BUG() reporting"
depends on DEBUG_KERNEL
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/sparc/Kconfig%LOGBUF Sun Dec 15 18:07:42 2002
+++ ./arch/sparc/Kconfig Mon Dec 16 21:17:40 2002
@@ -1414,6 +1414,43 @@
If you say Y here, various routines which may sleep will become very
noisy if they are called with a spinlock held.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/sparc64/Kconfig%LOGBUF Sun Dec 15 18:08:16 2002
+++ ./arch/sparc64/Kconfig Mon Dec 16 21:18:14 2002
@@ -1702,6 +1702,43 @@
depends on STACK_DEBUG
default y
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/ppc/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/ppc/Kconfig Mon Dec 16 21:10:24 2002
@@ -1866,6 +1866,43 @@
bool "Support for early boot texts over serial port"
depends on 4xx || GT64260 || LOPEC || MCPN765 || PPLUS || PRPMC800 || SANDPOINT || ZX4500
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/m68knommu/Kconfig%LOGBUF Sun Dec 15 18:08:13 2002
+++ ./arch/m68knommu/Kconfig Mon Dec 16 21:07:56 2002
@@ -751,6 +751,43 @@
help
Disable the CPU's BDM signals.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/alpha/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/alpha/Kconfig Mon Dec 16 21:00:23 2002
@@ -1022,6 +1022,43 @@
verbose debugging messages. If you suspect a semaphore problem or a
kernel hacker asks for this option then say Y. Otherwise say N.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/cris/Kconfig%LOGBUF Sun Dec 15 18:08:19 2002
+++ ./arch/cris/Kconfig Mon Dec 16 21:06:09 2002
@@ -751,6 +751,43 @@
depends on PROFILE
default "2"
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/mips/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/mips/Kconfig Mon Dec 16 21:08:44 2002
@@ -1276,6 +1276,43 @@
depends on SMP
default "32"
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/x86_64/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/x86_64/Kconfig Mon Dec 16 21:20:19 2002
@@ -692,6 +692,43 @@
symbolic stack backtraces. This increases the size of the kernel
somewhat, as all symbols have to be loaded into the kernel image.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/ppc64/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/ppc64/Kconfig Mon Dec 16 21:10:33 2002
@@ -551,6 +551,43 @@
bool "Include PPCDBG realtime debugging"
depends on DEBUG_KERNEL
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/um/Kconfig%LOGBUF Sun Dec 15 18:07:57 2002
+++ ./arch/um/Kconfig Mon Dec 16 21:18:35 2002
@@ -169,5 +169,42 @@
bool "Enable gcov support"
depends on DEBUGSYM
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
--- ./arch/arm/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/arm/Kconfig Mon Dec 16 21:05:34 2002
@@ -1220,6 +1220,43 @@
output to the second serial port on these devices. Saying N will
cause the debug messages to appear on the first serial port.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/parisc/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/parisc/Kconfig Mon Dec 16 21:09:21 2002
@@ -415,6 +415,43 @@
symbolic stack backtraces. This increases the size of the kernel
somewhat, as all symbols have to be loaded into the kernel image.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/ia64/Kconfig%LOGBUF Sun Dec 15 18:08:21 2002
+++ ./arch/ia64/Kconfig Mon Dec 16 21:07:20 2002
@@ -886,6 +886,43 @@
and restore instructions. It's useful for tracking down spinlock
problems, but slow! If you're unsure, select N.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/mips64/Kconfig%LOGBUF Sun Dec 15 18:07:52 2002
+++ ./arch/mips64/Kconfig Mon Dec 16 21:09:00 2002
@@ -719,6 +719,43 @@
depends on SMP
default "64"
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/s390x/Kconfig%LOGBUF Sun Dec 15 18:07:59 2002
+++ ./arch/s390x/Kconfig Mon Dec 16 21:10:59 2002
@@ -338,6 +338,43 @@
If you say Y here, various routines which may sleep will become very
noisy if they are called with a spinlock held.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/v850/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/v850/Kconfig Mon Dec 16 21:19:06 2002
@@ -444,6 +444,43 @@
help
Disable the CPU's BDM signals.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/sh/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/sh/Kconfig Mon Dec 16 21:17:31 2002
@@ -1268,6 +1268,43 @@
when the kernel may crash or hang before the serial console is
initialised. If unsure, say N.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
--- ./arch/s390/Kconfig%LOGBUF Sun Dec 15 18:07:54 2002
+++ ./arch/s390/Kconfig Mon Dec 16 21:10:49 2002
@@ -329,6 +329,43 @@
If you say Y here, various routines which may sleep will become very
noisy if they are called with a spinlock held.
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_128KB if ARCH_S390
+ default LOG_BUF_64KB if X86_NUMAQ || IA64
+ default LOG_BUF_32KB if SMP
+ default LOG_BUF_16KB
+ help
+ Select kernel log buffer size from this list.
+ Defaults: 16 KB for uniprocessor
+ 32 KB for SMP
+ 64 KB for x86 NUMAQ or IA-64
+ 128 KB for S/390
+
+config LOG_BUF_128KB
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_64KB
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_32KB
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_16KB
+ bool "16 KB"
+
+endchoice
+
+config LOG_BUF_LEN
+ int
+ default 131072 if LOG_BUF_128KB
+ default 65536 if LOG_BUF_64KB
+ default 32768 if LOG_BUF_32KB
+ default 16384 if LOG_BUF_16KB
+
endmenu
source "security/Kconfig"
^ permalink raw reply
* [LARTC] PRIO type qdisc
From: Paul C. Diem @ 2002-12-17 6:05 UTC (permalink / raw)
To: lartc
I'm looking for a PRIO type qdisc which will prioritize packets (either
based on DS or filters). Unlike PRIO, I need all the classes to flow into
a single qdisc (HTB). For example:
PRIO
|
+--------+--------+
| | |
Band0 Band1 Band2
| | |
+--------+--------+
|
HTB
Does such a qdisc exist or is there a way to get all the PRIO classes to
flow into a single qdisc?
Paul C. Diem
PCDiem@FoxValley.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 6:09 UTC (permalink / raw)
To: Dave Jones; +Cc: Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162140500.1644-100000@home.transmeta.com>
On Mon, 16 Dec 2002, Linus Torvalds wrote:
>
> On my P4 machine, a "getppid()" is 641 cycles with sysenter/sysexit, and
> something like 1761 cycles with the old "int 0x80/iret" approach. That's a
> noticeable improvement, but I have to say that I'm a bit disappointed in
> the P4 still, it shouldn't be even that much.
On a slightly more real system call (gettimeofday - which actually matters
in real life) the difference is still visible, but less so - because the
system call itself takes more of the time, and the kernel entry overhead
is thus not as clear.
For gettimeofday(), the results on my P4 are:
sysenter: 1280.425844 cycles
int/iret: 2415.698224 cycles
1135.272380 cycles diff
factor 1.886637
ie sysenter makes that system call almost twice as fast.
It's not as good as a pure user-mode solution using tsc could be, but
we've seen the kinds of complexities that has with multi-CPU systems, and
they are so painful that I suspect the sysenter approach is a lot more
palatable even if it doesn't allow for the absolute best theoretical
numbers.
Linus
^ permalink raw reply
* Re: [BUG] module-init-tools 0.9.3, rmmod modules with '-'
From: Vamsi Krishna S . @ 2002-12-17 6:18 UTC (permalink / raw)
To: Rusty Russell; +Cc: Zwane Mwaikambo, lkml
In-Reply-To: <20021217002740.598D32C05B@lists.samba.org>
On Tue, Dec 17, 2002 at 11:17:05AM +1100, Rusty Russell wrote:
>
> BTW, this was done for (1) simplicity, (2) so KBUILD_MODNAME can be
> used to construct identifiers, and (3) so parameters when the module
> is built-in have a consistent name.
>
Ok, I see it now, this magic happens in scripts/Makefile.lib.
My module has been built outside the kernel build system, that's
why I saw this problem.
I guess avoiding '-' should do it, but is there a simple way to
correctly build (simple, test) modules outside the kernel tree now?
Thanks,
Vamsi.
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 5:55 UTC (permalink / raw)
To: Dave Jones; +Cc: Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212161832420.12062-100000@home.transmeta.com>
On Mon, 16 Dec 2002, Linus Torvalds wrote:
>
> (Modulo the missing syscall page I already mentioned and potential bugs
> in the code itself, of course ;)
Ok, I did the vsyscall page too, and tried to make it do the right thing
(but I didn't bother to test it on a non-SEP machine).
I'm pushing the changes out right now, but basically it boils down to the
fact that with these changes, user space can instead of doing an
int $0x80
instruction for a system call just do a
call 0xfffff000
instead. The vsyscall page will be set up to use sysenter if the CPU
supports it, and if it doesn't, it will just do the old "int $0x80"
instead (and it could use the AMD syscall instruction if it wants to).
User mode shouldn't know or care, the calling convention is the same as it
ever was.
On my P4 machine, a "getppid()" is 641 cycles with sysenter/sysexit, and
something like 1761 cycles with the old "int 0x80/iret" approach. That's a
noticeable improvement, but I have to say that I'm a bit disappointed in
the P4 still, it shouldn't be even that much.
As a comparison, an Athlon will do a full int/iret faster than a P4 does a
sysenter/sysexit. Pathetic. But it's better than it used to be.
Whatever. The code is extremely simple, and while I'm sure there are
things I've missed I'd love to hear if this works for anybody else. I'm
appending the (extremely stupid) test-program I used to test it.
The way I did this, things like system call restarting etc _should_ all
work fine even with "sysenter", simply by virtue of both sysenter and "int
0x80" being two-byte opcodes. But it might be interesting to verify that a
recompiled glibc (or even just a preload) really works with this on a
"whole system" testbed rather than just testing one system call (and not
even caring about the return value) a million times.
The good news is that the kernel part really looks pretty clean.
Linus
---
#include <time.h>
#include <sys/time.h>
#include <asm/unistd.h>
#include <sys/stat.h>
#include <stdio.h>
#define rdtsc() ({ unsigned long a,d; asm volatile("rdtsc":"=a" (a), "=d" (d)); a; })
int main()
{
int i, ret;
unsigned long start, end;
start = rdtsc();
for (i = 0; i < 1000000; i++) {
asm volatile("call 0xfffff000"
:"=a" (ret)
:"0" (__NR_getppid));
}
end = rdtsc();
printf("%f cycles\n", (end - start) / 1000000.0);
start = rdtsc();
for (i = 0; i < 1000000; i++) {
asm volatile("int $0x80"
:"=a" (ret)
:"0" (__NR_getppid));
}
end = rdtsc();
printf("%f cycles\n", (end - start) / 1000000.0);
}
^ permalink raw reply
* Re: ide-scsi in 2.5.51
From: Andre Hedrick @ 2002-12-17 5:42 UTC (permalink / raw)
To: Willem Riede; +Cc: linux-scsi
In-Reply-To: <20021214202254.GH3664@linnie.riede.org>
Willem,
Please jump on it!
On Sat, 14 Dec 2002, Willem Riede wrote:
> In my efforts to make osst work on 2.5.51 I've been pretty successful with
> the SC-30 (scsi) and the FW-30 (ieee1394). But the ide-scsi is giving me
> trouble with the DI-30 (Atapi). I get the same problem with another ide
> connected tape drive and st, by the way, so I am taking a closer look at
> ide-scsi. When I load the module I get:
>
>
> Dec 14 14:50:55 fallguy kernel: Badness in kobject_register at lib/kobject.c:113
> Dec 14 14:50:55 fallguy kernel: Call Trace:
> Dec 14 14:50:55 fallguy kernel: [<c01c7c88>] kobject_register+0x58/0x70
> Dec 14 14:50:55 fallguy kernel: [<c01db442>] bus_add_driver+0x82/0xd0
> Dec 14 14:50:55 fallguy kernel: [<c022bd00>] ide_drive_remove+0x0/0x30
> Dec 14 14:50:55 fallguy kernel: [<c022bdec>] ide_register_driver+0xbc/0xf0
> Dec 14 14:50:55 fallguy kernel: [<c0133f6a>] sys_init_module+0x1ba/0x1d0
> Dec 14 14:50:55 fallguy kernel: [<c010b643>] syscall_call+0x7/0xb
> Dec 14 14:50:55 fallguy kernel:
> Dec 14 14:50:55 fallguy kernel: scsi HBA driver idescsi didn't set max_sectors, please fix the template
> <3>ERROR: SCSI host `ide-scsi' has no error handling
> Dec 14 14:50:55 fallguy kernel: ERROR: This is not a safe way to run your SCSI host
> Dec 14 14:50:55 fallguy kernel: ERROR: The error handling must be added to this driver
> Dec 14 14:50:55 fallguy kernel: Call Trace:
> Dec 14 14:50:55 fallguy kernel: [<c023687d>] scsi_register+0x2cd/0x2e0
> Dec 14 14:50:55 fallguy kernel: [<c02368be>] scsi_register_host+0x2e/0xe0
> Dec 14 14:50:55 fallguy kernel: [<c0133f6a>] sys_init_module+0x1ba/0x1d0
> Dec 14 14:50:55 fallguy kernel: [<c010b643>] syscall_call+0x7/0xb
> Dec 14 14:50:55 fallguy kernel:
> Dec 14 14:50:55 fallguy kernel: scsi4 : SCSI host adapter emulation for IDE ATAPI devices
>
>
> So it seems that ide-scsi hasn't kept up with the evolving 2.5 kernel.
> If no-one else is working on this, I'm prepared to take a stab at it,
> but to get me jump-started any advise / hint will be most welcome.
>
> Thanks, Willem Riede.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun()
From: Doug Ledford @ 2002-12-17 5:41 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: linux-scsi
In-Reply-To: <170040000.1040080786@aslan.btc.adaptec.com>
On Mon, Dec 16, 2002 at 04:19:46PM -0700, Justin T. Gibbs wrote:
> In debugging a different bug in the new 2.5.X port of the aic7xxx driver,
> I came across this behavior in scsi_probe_and_add_lun()
>
> /*
> * Since we reuse the same sdevscan over and over with different
> * target and lun values, we have to destroy and then recreate
> * any possible low level attachments since they very will might
> * also store the id and lun numbers in some form and need updating
> * with each scan.
> */
> if (sdevscan->host->hostt->slave_destroy)
> sdevscan->host->hostt->slave_destroy(sdevscan);
> if (sdevscan->host->hostt->slave_alloc)
> sdevscan->host->hostt->slave_alloc(sdevscan);
>
> So, you cannot rely on slave_destroy as an indication of a device really
> going away in the physical sense.
No, you can. In the code snippet above you might be destroying something
at scsi0:0:0:0 and adding something at scsi0:0:1:0. Regardless, the thing
being destroyed is in fact going away permanently. Whenever we do find a
device, we actually allocate a new device struct identical to our current
device struct and call slave_alloc() for the newly created device. So,
whenever we find a new device, there will be a momentary point in time at
which two device structs will exist that point to the same device. After
the new device is allocated and set up, the original sdevscan device is
simply renumbered in place (by updating the target or lun value) and then
we call slave_destroy()/slave_alloc() so that the low level driver can
also update their target/lun values to match.
> In SPI, for example, the driver can only
> tell that the device is gone if a command is issued to it. I had hoped that
> I could detect hot-pull/scsi-remove-single-device operations via this
> callback.
You can. On any device we find, at device tear down time your
slave_destroy() entry point will get called right before the device struct
itself is kfree()ed.
> Granted, for some drivers, recreating and destroying state associated with a
> particular device might be pretty cheap, but certainly not in all cases.
> The
> aic7xxx and aic79xx drivers maintain domain validation and other negotiation
> state in these structures. You certainly don't want to go through another
> full
> Domain Validation sequence the next time a device is allocated via
> slave_alloc() if the device isn't really "new".
In this case I would suggest that the better course of action is to delay
any domain validation stuff until the slave_configure() call. The
original intent of slave_alloc() was for it to be as lightweight as
possible simply because I knew that it would get called for every single
target/lun value scanned. Once we do find a device though, and once we
have retrieved INQUIRY data so we know what the device is capable of, then
we get the slave_configure() call which is a much more appropriate place
for heavier initializations once you know a device has been found and not
that we are just scanning.
> Any chance in changing this behavior?
Possibly. But, does the explanation above and the one suggestion above
solve your issues?
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
^ permalink raw reply
* Re: increase base memory
From: Sergey Suleymanov @ 2002-12-17 5:39 UTC (permalink / raw)
To: Linux-MSDOS Mailing list
In-Reply-To: <3DFE16C2.8000600@yahoo.com>
>>>>> Stas Sergeev writes:
Stas> should be willing to do this? You can use UMB and HMA, is it
Stas> not enough? Well, if that is just a comparison with 0.99.13,
Of course it is.
--
Sergey Suleymanov
^ permalink raw reply
* RE: bandwidth management
From: Azher Amin @ 2002-12-17 5:37 UTC (permalink / raw)
To: 'Imran Ali Rashid', linux-admin
In-Reply-To: <002b01c2a500$75656ec0$4000a8c0@Imran>
You can use HTB, with kernel 2.4.20. That’s a better way to cope the
spare bandwidth. Try http://sourceforge.net/projects/htbinit/
Azher
-----Original Message-----
From: linux-admin-owner@vger.kernel.org
[mailto:linux-admin-owner@vger.kernel.org] On Behalf Of Imran Ali Rashid
Sent: Monday, December 16, 2002 5:41 PM
To: linux-admin@vger.kernel.org
Subject: bandwidth management
Hey people.
I need some help with bandwidth management.
we need a situation where one person isn't able to hog all the bandwidth
to
himself.
stochastic fair queueing isn't giving a fair enough queueing system.
i need a solution with better queueing. CPU usage isn't an issue.
Temporarily we're using CBQ to limit bandwidth, however its not a
preferred
solution since the bandwidth is limited even when there is bandwidth to
spare.
-
To unsubscribe from this list: send the line "unsubscribe linux-admin"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" 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
* [PATCH]: linux-2.5.52-uc0 (MMU-less fix ups)
From: Greg Ungerer @ 2002-12-17 5:20 UTC (permalink / raw)
To: linux-kernel
Hi All,
An update of the uClinux (MMU-less) fixups against 2.5.52.
There was a couple of minor fixups needed (over 2.5.51).
The bulk of this patch is still the merge of the linker
scripts, entry.S and startup code.
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.52-uc0.patch.gz
Changelog:
1. patch against 2.5.52 (me)
2. C99 initializers in m68knommu setup.c (Art Haas)
Also updated:
. Motorola 68328 framebuffer driver
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.52-uc0-68328fb.patch.gz
. Hitachi H8300 achitecture support
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.52-uc0-h8300.patch.gz
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: gerg@snapgear.com
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com
^ permalink raw reply
* Problem using "make config/xconfig" with 2.4.20 on Redhat 7.3
From: Joseph D. Wagner @ 2002-12-17 4:38 UTC (permalink / raw)
To: Linux Kernel
I must be doing something wrong, but I can't figure out what.
I've downloaded kernel version 2.4.20 from http://www.kernel.org and copied
it to the /usr/src/linux-2.4.20 directory, but when I do "make xconfig" (or
any other "make" for that matter, it exits with error code 2.
I figure there is some Redhat-specific tweaking I must do to compile a
generic kernel from http://www.kernel.org on a Redhat system, but I have no
idea what that specific tweaking is. The people at the Redhat-devel list
were of no help so I'm turning to you guys.
Could someone help me, please?
BTW, I'm using Redhat Linux 7.3.
Here's my output from "make xconfig":
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory `/usr/src/linux-2.4.20/scripts'
cat header.tk >> ./kconfig.tk
./tkparse < ../arch/i386/config.in >> kconfig.tk
-: 6: unknown command
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.20/scripts'
make: *** [xconfig] Error 2
TIA
Joseph Wagner
^ permalink raw reply
* [PATCH] better compat_jiffies_to_clock_t
From: Stephen Rothwell @ 2002-12-17 4:25 UTC (permalink / raw)
To: Linus; +Cc: LKML, davidm
Hi Linus,
At David Mosberger's suggestion can we use this new version of
compat_jiffies_to_clock_t? It does better rounding and will not fail
if COMPAT_USER_HZ > HZ.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff -ruN 2.5.52-32bit.base/include/linux/compat.h 2.5.52-32bit.clock/include/linux/compat.h
--- 2.5.52-32bit.base/include/linux/compat.h 2002-12-16 14:49:54.000000000 +1100
+++ 2.5.52-32bit.clock/include/linux/compat.h 2002-12-17 15:20:18.000000000 +1100
@@ -9,9 +9,11 @@
#ifdef CONFIG_COMPAT
#include <linux/stat.h>
+#include <linux/param.h> /* for HZ */
#include <asm/compat.h>
-#define compat_jiffies_to_clock_t(x) ((x) / (HZ / COMPAT_USER_HZ))
+#define compat_jiffies_to_clock_t(x) \
+ (((unsigned long long)(x) * COMPAT_USER_HZ) / HZ)
struct compat_utimbuf {
compat_time_t actime;
^ permalink raw reply
* Re: [PATCH] : More module parameter compatibility for 2.5.52
From: Rusty Russell @ 2002-12-17 4:20 UTC (permalink / raw)
To: jt; +Cc: Linux kernel mailing list, Jeff Garzik
In-Reply-To: <20021217012646.GA18021@bougret.hpl.hp.com>
In message <20021217012646.GA18021@bougret.hpl.hp.com> you write:
> Hi,
>
> I've just downloaded 2.5.52 to try the new module parameter
> support. Unfortunately, the letter 'c' was not implemented, and I need
> it. This is used in few drivers (such as hp100, wavelan, wlan_cs...).
Cool, an undocumented type! And they have explit sizes, and they're
used in arrays. Just wonderful.
I prefer the fix below. Does it work for you?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Name: Implement c in MODULE_PARM compatibility wedge
Author: Rusty Russell and Jean Tourrilhes
Status: Experimental
D: The "c" MODULE_PARM type was missing, as pointed out by Jean Tourrilhes.
diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.52/kernel/module.c working-2.5.52-cparam/kernel/module.c
--- linux-2.5.52/kernel/module.c Tue Dec 17 08:11:03 2002
+++ working-2.5.52-cparam/kernel/module.c Tue Dec 17 14:42:05 2002
@@ -569,10 +569,19 @@ static int param_string(const char *name
return 0;
}
+/* Bounds checking done below */
+static int obsparm_copy_string(const char *val, struct kernel_param *kp)
+{
+ strcpy(kp->arg, val);
+ return 0;
+}
+
extern int set_obsolete(const char *val, struct kernel_param *kp)
{
unsigned int min, max;
- char *p, *endp;
+ unsigned int size, maxsize;
+ char *endp;
+ const char *p;
struct obsolete_modparm *obsparm = kp->arg;
if (!val) {
@@ -605,8 +614,29 @@ extern int set_obsolete(const char *val,
sizeof(long), param_set_long);
case 's':
return param_string(kp->name, val, min, max, obsparm->addr);
+
+ case 'c':
+ /* Undocumented: 1-5c50 means 1-5 strings of up to 49 chars,
+ and the decl is "char xxx[5][50];" */
+ p = endp+1;
+ maxsize = simple_strtol(p, &endp, 10);
+ /* We check lengths here (yes, this is a hack). */
+ p = val;
+ while (p[size = strcspn(p, ",")]) {
+ if (size >= maxsize)
+ goto oversize;
+ p += size+1;
+ }
+ if (size >= maxsize)
+ goto oversize;
+ return param_array(kp->name, val, min, max, obsparm->addr,
+ maxsize, obsparm_copy_string);
}
printk(KERN_ERR "Unknown obsolete parameter type %s\n", obsparm->type);
+ return -EINVAL;
+ oversize:
+ printk(KERN_ERR
+ "Parameter %s doesn't fit in %u chars.\n", kp->name, maxsize);
return -EINVAL;
}
^ permalink raw reply
* [PATCH] Priority-based real-time futexes v1.1 for 2.5.52
From: Inaky Perez-Gonzalez @ 2002-12-17 4:19 UTC (permalink / raw)
To: linux-kernel, rusty
This is the priority-based futex support; tasks/fds that are
sleeping on a futex get woken up by priority order. This is useful
for real-time locking, with most benefits being for the NGPT and
NPTL thread libraries. Checkout the CAVEATS section for a PRIORITY
INVERSION problem that needs sollution.
How it works is: there is one struct futex_q per futex; each
futex_q contains a priority array [it requires the prioarray-1.0
patch] where the waiters are attached [the waiter, struct futex_w,
describes the task and fd if any). The last waiter takes care of
freeing the futex_q.
When a wake up is selected, the prioarray is walked in priority order
to wake up as many waiters as specified. All list operations are
O(1). The only one operation that is O(N) is sys_poll() [on the number
of fds being waited for, as always].
Changelog since last patch:
- vcache callback: having to create a new futex_q struct in the
callback creates a failure point if there is no more GFP_ATOMIC
space; the corresponding waiter would be deattached from any
futex_q and thus, lay there sleeping for ever.
The only sollution I can think of is wake it up, so it goes up
to user space, sees the count is still -1 [or whatever] and if
required, go back down to the kernel and sleep there.
- Added futex_wait_utime() split by Luca Barbieri.
- Define futex_w_is_queued() so we don't test manually q->NULL
[in case it changes IANF].
- Some silly pretty print and cosmetic changes.
Older changelog:
- Updated docs here and there, add explanation of the model and a
short roadmap.
- Don't depend so much in GFP_ATOMIC - this forces us to lookup
with __get_futex_q() twice when there is no futex_q, and that
is ugly. Need to improve it (CR caveats).
- Fixed a bunch of embarrasing error paths [let's see how many
did I introduce]
Remaining CAVEATS:
- Priority inversion problem: in the current futex model, when we
wake up, in userspace, we set the futex count to 1 and then go
down to the kernel to ask it to wake up so many
waiters. Between setting the futex count to 1 and the kernel
waking up the highest priority waiter(s), some lower priority
process could acquire the futex and cause a priority
inversion.
To fix this, I can only thing of improving the current
FUTEX_PASS mechanism to work inside the kernel, so that the
futex does not need to be set to 1 when there are waiters.
- Not everybody/task/futex cares about priority based wake-up,
and they consume some space (140 * 2 * 4 bytes each futex_q
for the prioarray index plus associated stuff) [more than 1K in
total].
I am planning that I could have the first locker specify how
it should behave, and then, dynamically select either a
normal queue or a pqueue, with that selection in effect for
the lifetime of the futex in kernel space [ie: while it is
locked].
- I took special care not to miss anything allocated when it
should, but I could have screwed up ...
- Optimize lookup and possible creation of a new futex_q
- Use an slab allocator for the futex_q. On applications with a
low contention rate, we don't want to be allocating and
deallocating an struct futex_q every time just because the
futex is locked by nobody, one or two people in a random
distribution. If the slab is there, the futex_q will remain
allocated, so acquisition will be faster and fragmentation
lower. When memory is tight, and it is not used, it will be
released.
I used a combination of code that I borrowed from NGPT, Rusty's
user space sample library + some of my own to test it. It is
basically a shared area and futex_down and futex_up programs
that can be called from the shell. I gave it a few hard times
and it resisted pretty well - however, I probably missed many
cases. Find it at:
http://sost.net/pub/linux/pfutex-test.tar.gz
Enjoy
This patch requires the following patches and kernel version:
linux-2.5.52 prioarray-1.0
diff -u include/linux/vcache.h:1.1.1.1 include/linux/vcache.h:1.1.1.1.4.1
--- include/linux/vcache.h:1.1.1.1 Wed Dec 11 11:06:00 2002
+++ include/linux/vcache.h Mon Dec 16 17:46:07 2002
@@ -17,8 +17,26 @@
unsigned long address,
struct mm_struct *mm,
void (*callback)(struct vcache_s *data, struct page *new_page));
+static inline
+void attach_vcache (vcache_t *vcache,
+ unsigned long address,
+ struct mm_struct *mm,
+ void (*callback)(struct vcache_s *data, struct page *new_page))
+{
+ spin_lock (&vcache_lock);
+ __attach_vcache (vcache, address, mm, callback);
+ spin_unlock (&vcache_lock);
+}
extern void __detach_vcache(vcache_t *vcache);
+
+static inline
+void detach_vcache (vcache_t *vcache)
+{
+ spin_lock (&vcache_lock);
+ __detach_vcache (vcache);
+ spin_unlock (&vcache_lock);
+}
extern void invalidate_vcache(unsigned long address, struct mm_struct *mm,
struct page *new_page);
diff -u kernel/futex.c:1.1.1.1.2.1 kernel/futex.c:1.1.1.1.4.4
--- kernel/futex.c:1.1.1.1.2.1 Wed Dec 11 13:28:03 2002
+++ kernel/futex.c Fri Dec 13 17:48:53 2002
@@ -11,6 +11,8 @@
*
* Generalized futexes for every mapping type, Ingo Molnar, 2002
*
+ * Priority-based wake up support (C) 2002 Intel Corp, Inaky
+ * Perez-Gonzalez <inaky.perez-gonzalez@intel.com>.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -24,8 +26,73 @@
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * FIXME: a slab allocator for futex_q and futex_w might be
+ * interesting.
+ *
+ *
+ * THEORY OF OPERATION [FIXME: I might have some areas wrong, help? thx]
+ *
+ * We want a user-space, inter-process lock that is fast to acquire
+ * when unlocked and that sleeps in the kernel if locked. Same story
+ * when releasing [no kernel access when only only one locker].
+ *
+ * So here come futexes. They are an integer in memory [possibly
+ * shared by different clones (normal lock) or processes (shared
+ * lock)]. If it's value is:
+ *
+ * 1 It is unlocked
+ * N (N > 1) It is unlocked N-1 times, need N locks to lock it
+ * 0 It is locked - no waiters
+ * -1 It is locked - one or more waiters
+ *
+ * Acquisition of unlocked futex:
+ *
+ * locker process is in userspace, atomically decreases the futex,
+ * if the value its zero, you got it.
+ *
+ * Acquisition of locked futex:
+ *
+ * locker tries to lock, sees it is not one, so it goes down to the
+ * kernel and either wait or assign an fd/signal (when you get it
+ * the waiter is woken up or the fd is signalled - eg: select())
+ *
+ * Release of locked futex:
+ *
+ * releaser goes to the kernel, says 'release', the kernel wakes up
+ * or signals as many waiters waiting on the futex as the releaser
+ * indicates.
+ *
+ *
+ * INNER KERNEL THEORY OF OPERATION
+ *
+ * Each futex is uniquely identified to a page+offset pair. Associated
+ * to it there is an 'struct futex_q'; a hash table protected by
+ * futex_lock is used to keep all the futex_q together.
+ *
+ * Waiters put the wait information [task, fd, signal...] in struct
+ * futex_w, that is added to the priority array in the futex_q.
+ *
+ * When locking, [futex_wait(), futex_fd()] a futex_q is looked up
+ * in the hash table [__get_futex_q()]; if none, a new one is created
+ * [maybe_new_futex_q] and the waiter data is initialized and added to
+ * it [queue_me]; futex_w->q indicates the state [queued/unqueued].
+ *
+ * When unlocking, futex_wake() locates the futex_q for the futex and
+ * then tell_waiters() selects the first N waiters to be woken up [N =
+ * param to futex_wake]. Then it removes the waiters from the futex_q;
+ * when done, if the futex_q is empty, it is disposed.
+ *
+ *
+ * QUICK ROADMAP:
+ *
+ * *_futex_q() functions to alloc/initialize/insert in hash and
+ * destroy and dispose a futex_q.
+ *
+ * sys_futex() Multiplex to futex_fd(), futex_wait() or futex_wake()
*/
+
#include <linux/slab.h>
#include <linux/poll.h>
#include <linux/file.h>
@@ -37,24 +104,65 @@
#define FUTEX_HASHBITS 8
+#define FUTEX_DEBUG 0
+
+#define futex_fdebug(f, a...) \
+if (f) { \
+ printk ("futex-debug: %s ", __FUNCTION__); \
+ printk (a); \
+}
+
+#define futex_debug(a...) futex_fdebug (FUTEX_DEBUG, a);
+
+
+/*
+ * This is a guy waiting for the futex
+ *
+ * q is needed so that when the vcache callback is called, from the
+ * vcache we can get the futex_w, and to be able to remove the futex_w
+ * from the futex_q maintaining the pqueue semantics, we need to know
+ * the futex_q ... so there it is.
+ *
+ * Being there, it also serves to denote status. If (w->q != NULL), it
+ * means that the futex_w is in a list, and thus, w->list is valid. If
+ * NULL, it is outside of any list. [Use futex_w_is_queued()].
+ */
+
+struct futex_w {
+ struct list_head list;
+ struct futex_q *q; /* damn it ... need a backpointer */
+ wait_queue_head_t waiters;
+
+ /* the virtual => physical COW-safe cache */
+ vcache_t vcache;
+ task_t *task;
+ int fd;
+ struct file *filp;
+};
+
+
+/* Test if the futex_w is queued */
+
+static inline
+int futex_w_is_queued (const struct futex_w *w)
+{
+ return w->q != NULL;
+}
+
+
/*
- * We use this hashed waitqueue instead of a normal wait_queue_t, so
- * we can wake only the relevent ones (hashed queues may be shared):
+ * For every unique futex we have one of these; it contains a list of the
+ * people who is waiting for the futex to be released.
*/
struct futex_q {
struct list_head list;
- wait_queue_head_t waiters;
+ spinlock_t lock;
/* Page struct and offset within it. */
struct page *page;
int offset;
- /* the virtual => physical COW-safe cache */
- vcache_t vcache;
-
- /* For fd, sigio sent using these. */
- int fd;
- struct file *filp;
+ struct prio_array pa;
};
/* The key for the hash is the address + index + offset within page */
@@ -66,6 +174,7 @@
/* Futex-fs vfsmount entry: */
static struct vfsmount *futex_mnt;
+
/*
* These are all locks that are necessery to look up a physical
* mapping safely, and modify/search the futex hash, atomically:
@@ -73,17 +182,17 @@
static inline void lock_futex_mm(void)
{
spin_lock(¤t->mm->page_table_lock);
- spin_lock(&vcache_lock);
spin_lock(&futex_lock);
}
+
static inline void unlock_futex_mm(void)
{
spin_unlock(&futex_lock);
- spin_unlock(&vcache_lock);
spin_unlock(¤t->mm->page_table_lock);
}
+
/*
* The physical page is shared, so we can hash on its address:
*/
@@ -93,25 +202,173 @@
FUTEX_HASHBITS)];
}
-/* Waiter either waiting in FUTEX_WAIT or poll(), or expecting signal */
-static inline void tell_waiter(struct futex_q *q)
+
+/*
+ * Check out if there is an struct futex_q for the page and
+ * offset given in the hash table; if there is, return it;
+ *
+ * Hold the lock on futex_lock or expect problems ...
+ *
+ * FIXME: looking up backwards would help futex_wait()
+ */
+
+static inline
+struct futex_q * __get_futex_q (struct page *page, unsigned offset)
{
- wake_up_all(&q->waiters);
- if (q->filp)
- send_sigio(&q->filp->f_owner, q->fd, POLL_IN);
+ struct list_head *i, *head;
+ struct futex_q *q;
+
+ futex_debug ("(page %p, offset %u)\n", page, offset);
+
+ head = hash_futex (page, offset);
+ list_for_each (i, head) {
+ q = list_entry (i, struct futex_q, list);
+ if (q->page == page && q->offset == offset)
+ return q;
+ }
+ /* Didn't find it */
+ return NULL;
}
+
+/*
+ * Allocate an struct futex_q, initialize it and add it to the hash.
+ *
+ * gfp = GFP_{KERNEL,ATOMIC} for kmalloc()
+ *
+ * This will NOT acquire any locks
+ */
+
+static inline
+struct futex_q * new_futex_q (struct page *page, unsigned offset, int gfp)
+{
+ struct futex_q *q;
+
+ futex_debug ("(page %p, offset %u, gfp %d)\n", page, offset, gfp);
+
+ if ((q = kmalloc (sizeof (struct futex_q), gfp)) != NULL) {
+ q->page = page;
+ q->offset = offset;
+ spin_lock_init (&q->lock);
+ pa_init (&q->pa);
+ }
+ return q;
+}
+
+
+/* Create a new futex_q and MAYBE insert it into the hash table
+ *
+ * From the time we checked with __get_futex_q() if there was a
+ * futex_q for the page and offset combination requested, there might
+ * have been another thread, task or process that did the same and
+ * created and inserted into the hash table a futex_q for it (because
+ * we dropped the lock so we could use GFP_KERNEL). Thus, we need to
+ * allocate and then check again [now with the lock held], and if not
+ * there, insert it; if there, we need to use that and drop the
+ * allocation.
+ *
+ * If we are using the one we allocated, it is returned; if not [we
+ * reused something somebody put in the list], it returns NULL. In any
+ * case, the futex_q we have to use is put in *pq (NULL if out of
+ * memory).
+ *
+ * This ugly return scheme is needed for the error handling paths in
+ * futex_wait().
+ */
+
+static inline
+struct futex_q * maybe_new_futex_q (struct futex_q **pq,
+ struct page *page, unsigned offset)
+{
+ struct futex_q *q, *qp;
+
+ futex_debug ("(page %p, offset %u)\n", page, offset);
+
+ q = new_futex_q (page, offset, GFP_KERNEL);
+ if (unlikely (q == NULL)) {
+ *pq = NULL;
+ goto out_err;
+ }
+
+ spin_lock (&futex_lock);
+ qp = __get_futex_q (q->page, q->offset);
+ if (unlikely (qp != NULL)) {
+ kfree (q);
+ *pq = qp;
+ q = NULL;
+ }
+ else {
+ list_add_tail (&q->list, hash_futex (page, offset));
+ *pq = q;
+ }
+ spin_unlock (&futex_lock);
+out_err:
+ return q;
+}
+
+
+/* Remove an struct futex_q from the hash table and free it */
+static inline
+void __put_futex_q (struct futex_q *q)
+{
+ futex_debug ("(q %p)\n", q);
+
+ /* FIXME: may be we want to cache them and free when they are
+ * kind of old or need more [__get_futex_q() should be
+ * involved]. I say that because in a multithreaded program
+ * that has lots of contention, well, the allocator is going
+ * to suffer.
+ */
+ list_del (&q->list);
+ kfree (q);
+}
+
+
+/* If the 'struct futex_q' is still in use, do nothing; however, if
+ * empty, remove it from the hash table and release it. */
+static inline
+void __maybe_put_futex_q (struct futex_q *q)
+{
+ futex_debug ("(q %p)\n", q);
+
+ /* Is the futex_q empty? wipe it out
+ * FIXME: may be we want to cache them and free when they are
+ * kind of old or need more [__get_futex_q() should be
+ * involved]. I say that because in a multithreaded program
+ * that has lots of contention, well, the allocator is going
+ * to suffer.
+ */
+ if (q->pa.nr_active == 0) {
+ __put_futex_q (q);
+ }
+}
+
+
+static inline
+void maybe_put_futex_q (struct futex_q *q)
+{
+ futex_debug ("(q %p)\n", q);
+ if (unlikely (q->pa.nr_active == 0)) {
+ spin_lock (&futex_lock);
+ __maybe_put_futex_q (q);
+ spin_unlock (&futex_lock);
+ }
+}
+
+
/*
* Get kernel address of the user page and pin it.
*
* Must be called with (and returns with) all futex-MM locks held.
*/
-static struct page *__pin_page(unsigned long addr)
+static struct page *__pin_page (unsigned long addr)
{
struct mm_struct *mm = current->mm;
struct page *page, *tmp;
int err;
+ futex_debug ("(addr %lx)\n", addr);
+
/*
* Do a quick atomic lookup first - this is the fastpath.
*/
@@ -150,214 +407,376 @@
return page;
}
-static inline void unpin_page(struct page *page)
+
+static inline void unpin_page (struct page *page)
+{
+ futex_debug ("(page %p)\n", page);
+ put_page (page);
+}
+
+
+static void futex_vcache_callback (vcache_t *, struct page *);
+
+/* Enqueue a waiter in a futex_q obtained from __get_futex_q() [need
+ * to lock q->lock].
+ */
+static inline
+void queue_me (struct futex_q *q, struct futex_w *w, unsigned long uaddr)
+{
+ spin_lock (&q->lock);
+ pa_enqueue (&w->list, w->task->prio, &q->pa);
+ w->q = q;
+ /* We register a futex callback to this virtual address,
+ * to make sure a COW properly rehashes the futex-queue. */
+ attach_vcache(&w->vcache, uaddr, current->mm, futex_vcache_callback);
+ spin_unlock (&q->lock);
+}
+
+
+/* Unqueue. No need to lock. Return 1 if we were still queued (ie. 0
+ * means we were woken).
+ *
+ * The locking version return the page to ease out the race-condition
+ * free code in futex_close(). If it returns NULL, it means the
+ * futex_w waiter was not waiting for anything - if it returns the
+ * page address, it means it was waiting for a futex in that page.
+ */
+
+static inline
+void __unqueue_me (struct futex_w *w)
+{
+ futex_debug ("(w %p)\n", w);
+
+ detach_vcache (&w->vcache);
+ pa_dequeue (&w->list, w->task->prio, &w->q->pa);
+ w->q = NULL;
+}
+
+static inline
+struct page * unqueue_me (struct futex_w *w)
+{
+ struct futex_q *q = w->q;
+ struct page *page = NULL;
+
+ futex_debug ("(w %p)\n", w);
+
+ if (q) {
+ spin_lock (&q->lock);
+ page = w->q->page;
+ __unqueue_me (w);
+ spin_unlock (&q->lock);
+ maybe_put_futex_q (q);
+ }
+ return page;
+}
+
+
+/* Wake up as many guys as needed who are waiting for a futex
+ *
+ * howmany == UINTMAX means wake them up all, 1 wake only the first one, 2
+ * the two first ones ...
+ *
+ * It is not our task to kfree [if needed] the futex_w struct;
+ * that will be done either by when the filp is destroyed [it is the
+ * filp's private data or on exit of futex_wait() [it is a local
+ * there].
+ *
+ * However, if there are no more tasks waiting ... fousch, we wipe the
+ * futex_q. NEED TO HOLD THE FUTEX_LOCK WHEN CALLING THIS FUNCTION.
+ *
+ * Tasks are waken up by priority order; O(1).
+ *
+ * Returns how many tasks were woken up.
+ */
+
+static
+int tell_waiters (struct futex_q *q, unsigned howmany)
{
- put_page(page);
+ struct futex_w *w;
+ unsigned index;
+ int ret = 0;
+
+ futex_debug ("(q %p, howmany %d): waking up waiters, %d waiting\n",
+ q, howmany, q->pa.nr_active);
+ if (!q)
+ BUG();
+
+ spin_lock (&q->lock);
+ if (unlikely (q->pa.nr_active == 0)) { /* Every body chickened out ... */
+ futex_debug ("(q %p, howmany %d): No active "
+ "tasks on the pqueue\n", q, howmany);
+ goto exit_put;
+ }
+
+ while (ret < howmany) {
+ index = sched_find_first_bit (q->pa.bitmap);
+ w = list_entry (q->pa.queue[index].next, struct futex_w, list);
+
+ __unqueue_me (w);
+ wake_up_process (w->task);
+ if (w->filp)
+ send_sigio (&w->filp->f_owner, w->fd, POLL_IN);
+ ret++;
+
+ if (q->pa.nr_active == 0) /* no more */
+ goto exit_put;
+ }
+ spin_unlock (&q->lock);
+ return ret;
+
+ exit_put:
+ spin_unlock (&q->lock);
+ __put_futex_q (q);
+ return ret;
}
+
/*
* Wake up all waiters hashed on the physical page that is mapped
- * to this virtual address:
+ * to this virtual address.
+ *
+ * There is only one futex_q per futex, so once we find it, we just
+ * exit.
*/
-static int futex_wake(unsigned long uaddr, int offset, int num)
+
+static inline
+int futex_wake (unsigned long uaddr, int offset, int num)
{
- struct list_head *i, *next, *head;
struct page *page;
+ struct futex_q *q;
int ret = 0;
- lock_futex_mm();
+ futex_debug ("(uaddr %lx, offset %d, num %d)\n",
+ uaddr, offset, num);
- page = __pin_page(uaddr - offset);
+ lock_futex_mm();
+ page = __pin_page (uaddr - offset);
if (!page) {
unlock_futex_mm();
return -EFAULT;
}
-
- head = hash_futex(page, offset);
-
- list_for_each_safe(i, next, head) {
- struct futex_q *this = list_entry(i, struct futex_q, list);
-
- if (this->page == page && this->offset == offset) {
- list_del_init(i);
- __detach_vcache(&this->vcache);
- tell_waiter(this);
- ret++;
- if (ret >= num)
- break;
- }
- }
-
+ q = __get_futex_q (page, offset);
+ if (q)
+ ret = tell_waiters (q, num);
unlock_futex_mm();
- unpin_page(page);
-
+ unpin_page (page);
return ret;
}
+
/*
* This gets called by the COW code, we have to rehash any
* futexes that were pending on the old physical page, and
* rehash it to the new physical page. The pagetable_lock
* and vcache_lock is already held:
*/
-static void futex_vcache_callback(vcache_t *vcache, struct page *new_page)
-{
- struct futex_q *q = container_of(vcache, struct futex_q, vcache);
- struct list_head *head = hash_futex(new_page, q->offset);
-
- spin_lock(&futex_lock);
-
- if (!list_empty(&q->list)) {
- q->page = new_page;
- list_del(&q->list);
- list_add_tail(&q->list, head);
- }
-
- spin_unlock(&futex_lock);
-}
-static inline void __queue_me(struct futex_q *q, struct page *page,
- unsigned long uaddr, int offset,
- int fd, struct file *filp)
-{
- struct list_head *head = hash_futex(page, offset);
-
- q->offset = offset;
- q->fd = fd;
- q->filp = filp;
- q->page = page;
-
- list_add_tail(&q->list, head);
- /*
- * We register a futex callback to this virtual address,
- * to make sure a COW properly rehashes the futex-queue.
- */
- __attach_vcache(&q->vcache, uaddr, current->mm, futex_vcache_callback);
+static
+void futex_vcache_callback (vcache_t *vcache, struct page *new_page)
+{
+ struct futex_w *w = container_of (vcache, struct futex_w, vcache);
+ unsigned offset;
+ struct futex_q *old_q, *new_q;
+
+ futex_debug ("(vcache %p, page %p)\n", vcache, new_page);
+
+ spin_lock (&futex_lock);
+ old_q = w->q;
+ offset = old_q->offset;
+
+ new_q = __get_futex_q (new_page, offset);
+
+ if (old_q) {
+ spin_lock (&old_q->lock);
+ pa_dequeue (&w->list, w->task->prio, &old_q->pa);
+ spin_unlock (&old_q->lock);
+ __maybe_put_futex_q (old_q);
+ }
+
+ /* If there is no new queue [already], create it - use
+ * GFP_ATOMIC, as we hold the vcache and futex locks */
+
+ if (new_q == NULL) {
+ new_q = new_futex_q (new_page, offset, GFP_ATOMIC);
+ if (unlikely (new_q == NULL))
+ goto out_err;
+ list_add_tail (&new_q->list,
+ hash_futex (new_page, offset));
+ }
+
+ spin_lock (&new_q->lock);
+ pa_enqueue (&w->list, w->task->prio, &new_q->pa);
+ spin_unlock (&new_q->lock);
+ spin_unlock (&futex_lock);
+ return;
+
+out_err:
+ /* Cannot create the futex_q, so let's wake it up and have
+ * it see it is still locked and it needs to call back into the
+ * kernel. It is already removed from the wait queue. */
+ w->q = NULL;
+ wake_up_process (w->task);
+ if (w->filp)
+ send_sigio (&w->filp->f_owner, w->fd, POLL_IN);
+ spin_unlock (&futex_lock);
+ return;
}
-/* Return 1 if we were still queued (ie. 0 means we were woken) */
-static inline int unqueue_me(struct futex_q *q)
-{
- int ret = 0;
- spin_lock(&vcache_lock);
- spin_lock(&futex_lock);
- if (!list_empty(&q->list)) {
- list_del(&q->list);
- __detach_vcache(&q->vcache);
- ret = 1;
- }
- spin_unlock(&futex_lock);
- spin_unlock(&vcache_lock);
- return ret;
-}
+/* Wait for a futex to be released
+ *
+ * The process is simply pin the page where the futex is, get a
+ * futex_q, append to it futex_w we keep on the stack and wait.
+ *
+ * Watch out 'qp': for the error path, if set, it indicates we have
+ * allocated a futex_q and we have to put it.
+ *
+ * Return 0 if everything went ok
+ * < 0 errno code on error
+ */
-static int futex_wait(unsigned long uaddr,
- int offset,
- int val,
- unsigned long time)
+static
+int futex_wait (unsigned long uaddr, int offset, int val, unsigned long time)
{
- DECLARE_WAITQUEUE(wait, current);
int ret = 0, curval;
struct page *page;
- struct futex_q q;
+ struct futex_w w;
+ struct futex_q *q, *qp = NULL;
- init_waitqueue_head(&q.waiters);
+ futex_debug ("(uaddr %lx, offset %d, val %d, time %lu)\n",
+ uaddr, offset, val, time);
+ /* Get the futex_q for this futex after locking the page */
lock_futex_mm();
-
- page = __pin_page(uaddr - offset);
+ page = __pin_page (uaddr - offset);
if (!page) {
unlock_futex_mm();
return -EFAULT;
}
- __queue_me(&q, page, uaddr, offset, -1, NULL);
-
+ q = __get_futex_q (page, offset);
unlock_futex_mm();
+ /* No futex_q? get a new one, check mid-air collision */
+ if (q == NULL) {
+ qp = maybe_new_futex_q (&q, page, offset);
+ if (unlikely (q == NULL)) {
+ ret = -ENOMEM;
+ goto out_unpin;
+ }
+ }
+
/* Page is pinned, but may no longer be in this address space. */
- if (get_user(curval, (int *)uaddr) != 0) {
+ if (get_user (curval, (int *) uaddr) != 0) {
ret = -EFAULT;
- goto out;
+ goto out_err;
}
if (curval != val) {
ret = -EWOULDBLOCK;
- goto out;
+ goto out_err;
}
- /*
+
+ /*
* The get_user() above might fault and schedule so we
* cannot just set TASK_INTERRUPTIBLE state when queueing
- * ourselves into the futex hash. This code thus has to
+ * ourselves into the futex_q. This code thus has to
* rely on the FUTEX_WAKE code doing a wakeup after removing
* the waiter from the list.
*/
- add_wait_queue(&q.waiters, &wait);
- set_current_state(TASK_INTERRUPTIBLE);
- if (!list_empty(&q.list))
+
+ INIT_LIST_HEAD (&w.list);
+ w.q = NULL;
+
+ w.task = current;
+ w.fd = -1;
+ w.filp = NULL;
+
+ queue_me (q, &w, uaddr);
+ set_current_state (TASK_INTERRUPTIBLE);
+ if (futex_w_is_queued (&w)) /* aka: if we are queued */
time = schedule_timeout(time);
- set_current_state(TASK_RUNNING);
- /*
- * NOTE: we dont remove ourselves from the waitqueue because
- * we are the only user of it.
- */
- if (time == 0) {
+ set_current_state (TASK_RUNNING);
+
+ /* Now, what happened? */
+ if (time == 0) {
ret = -ETIMEDOUT;
goto out;
}
- if (signal_pending(current))
+ if (signal_pending (current))
ret = -EINTR;
out:
- /* Were we woken up anyway? */
- if (!unqueue_me(&q))
+ if (!unqueue_me (&w))
ret = 0;
- unpin_page(page);
+out_unpin:
+ unpin_page (page);
+ return ret;
+out_err:
+ /* We allocated it and won't use it, but somebody could have
+ * done it in the midle. */
+ if (qp) {
+ spin_lock (&futex_lock);
+ __maybe_put_futex_q (qp);
+ spin_unlock (&futex_lock);
+ }
+ unpin_page (page);
return ret;
}
-static inline int futex_wait_utime(unsigned long uaddr,
- int offset,
- int val,
- struct timespec* utime)
-{
- unsigned long time = MAX_SCHEDULE_TIMEOUT;
-
- if (utime) {
- struct timespec t;
- if (copy_from_user(&t, utime, sizeof(t)) != 0)
- return -EFAULT;
- time = timespec_to_jiffies(&t) + 1;
- }
+static inline
+int futex_wait_utime (unsigned long uaddr, int offset, int val,
+ struct timespec *utime)
+{
+ unsigned long time = MAX_SCHEDULE_TIMEOUT;
+
+ if (utime) {
+ struct timespec t;
+ if (copy_from_user (&t, utime, sizeof (t)) != 0)
+ return -EFAULT;
+ time = timespec_to_jiffies (&t) + 1;
+ }
- return futex_wait(uaddr, offset, val, time);
+ return futex_wait (uaddr, offset, val, time);
}
-static int futex_close(struct inode *inode, struct file *filp)
+
+/*
+ * Close the fd associated with a futex, cleanup the futex too.
+ */
+
+static
+int futex_close (struct inode *inode, struct file *filp)
{
- struct futex_q *q = filp->private_data;
+ struct futex_w *w = filp->private_data;
+ struct page *page;
- unqueue_me(q);
- unpin_page(q->page);
- kfree(filp->private_data);
+ page = unqueue_me (w);
+ if (page)
+ unpin_page (page);
+ kfree (filp->private_data);
return 0;
}
+
/* This is one-shot: once it's gone off you need a new fd */
-static unsigned int futex_poll(struct file *filp,
- struct poll_table_struct *wait)
+static
+unsigned int futex_poll (struct file *filp,
+ struct poll_table_struct *wait)
{
- struct futex_q *q = filp->private_data;
+ struct futex_w *w = filp->private_data;
int ret = 0;
- poll_wait(filp, &q->waiters, wait);
- spin_lock(&futex_lock);
- if (list_empty(&q->list))
+ futex_debug ("(filp %p, wait %p)\n", filp, wait);
+
+ poll_wait (filp, &w->waiters, wait);
+ spin_lock (&futex_lock); /* Lock only q? */
+ if (!futex_w_is_queued (w))
ret = POLLIN | POLLRDNORM;
- spin_unlock(&futex_lock);
+ spin_unlock (&futex_lock);
return ret;
}
+
static struct file_operations futex_fops = {
.release = futex_close,
.poll = futex_poll,
@@ -365,25 +784,29 @@
/* Signal allows caller to avoid the race which would occur if they
set the sigio stuff up afterwards. */
-static int futex_fd(unsigned long uaddr, int offset, int signal)
+static int futex_fd (unsigned long uaddr, int offset, int signal)
{
struct page *page = NULL;
struct futex_q *q;
+ struct futex_w *w;
struct file *filp;
- int ret;
+ int ret, fd;
ret = -EINVAL;
if (signal < 0 || signal > _NSIG)
- goto out;
+ goto out_err;
+ /* Set up a file descriptor to wait on. */
+
ret = get_unused_fd();
if (ret < 0)
- goto out;
+ goto out_err;
+ fd = ret;
+
filp = get_empty_filp();
if (!filp) {
- put_unused_fd(ret);
ret = -ENFILE;
- goto out;
+ goto out_err_get_empty_filp;
}
filp->f_op = &futex_fops;
filp->f_vfsmnt = mntget(futex_mnt);
@@ -393,55 +816,82 @@
int ret;
ret = f_setown(filp, current->tgid, 1);
- if (ret) {
- put_unused_fd(ret);
- put_filp(filp);
- goto out;
- }
+ if (ret)
+ goto out_err_f_setown;
filp->f_owner.signum = signal;
}
- q = kmalloc(sizeof(*q), GFP_KERNEL);
- if (!q) {
- put_unused_fd(ret);
- put_filp(filp);
- ret = -ENOMEM;
- goto out;
- }
-
+ /* Pull out what page the futex is at, pin it down so it does not
+ * dissapear off to swap space. */
+
lock_futex_mm();
-
page = __pin_page(uaddr - offset);
if (!page) {
- unlock_futex_mm();
-
- put_unused_fd(ret);
- put_filp(filp);
- kfree(q);
- return -EFAULT;
+ unlock_futex_mm();
+ ret = -EFAULT;
+ goto out_err_pin_page;
+ }
+
+ /* Pull out the futex queue corresponding to the futex. Create
+ * one if none. */
+
+ q = __get_futex_q (page, offset);
+ unlock_futex_mm();
+ if (q == NULL) {
+ maybe_new_futex_q (&q, page, offset);
+ if (unlikely (q == NULL)) {
+ ret = -ENOMEM;
+ goto out_err_get_futex_q;
+ }
+ }
+
+ /* Create a waiter structure, initialize it and queue it in
+ * the futex queue. */
+
+ w = kmalloc (sizeof (*w), GFP_KERNEL);
+ if (w == NULL) {
+ ret = -ENOMEM;
+ goto out_err_w_kmalloc;
}
- init_waitqueue_head(&q->waiters);
- filp->private_data = q;
+ INIT_LIST_HEAD (&w->list);
+ init_waitqueue_head (&w->waiters);
+ w->q = NULL;
+ w->task = current;
+ w->fd = fd;
+ w->filp = filp;
+ filp->private_data = w;
- __queue_me(q, page, uaddr, offset, ret, filp);
-
- unlock_futex_mm();
+ queue_me (q, w, uaddr);
/* Now we map fd to filp, so userspace can access it */
- fd_install(ret, filp);
- page = NULL;
-out:
- if (page)
- unpin_page(page);
+ fd_install (ret, filp);
return ret;
+
+out_err_w_kmalloc:
+ maybe_put_futex_q (q);
+out_err_get_futex_q:
+ unpin_page (page);
+out_err_pin_page:
+out_err_f_setown:
+ put_filp (filp);
+out_err_get_empty_filp:
+ put_unused_fd (fd);
+out_err:
+ return ret;
}
-asmlinkage int sys_futex(unsigned long uaddr, int op, int val, struct timespec *utime)
+
+/* System call for the futex: multiplex the actual operation */
+
+asmlinkage
+int sys_futex (unsigned long uaddr, int op, int val, struct timespec *utime)
{
unsigned long pos_in_page;
int ret;
+ futex_debug ("(%lx, %d, %d, %p)\n", uaddr, op, val, utime);
+
pos_in_page = uaddr % PAGE_SIZE;
/* Must be "naturally" aligned */
@@ -450,14 +900,14 @@
switch (op) {
case FUTEX_WAIT:
- ret = futex_wait_utime(uaddr, pos_in_page, val, utime);
+ ret = futex_wait_utime (uaddr, pos_in_page, val, utime);
break;
case FUTEX_WAKE:
- ret = futex_wake(uaddr, pos_in_page, val);
+ ret = futex_wake (uaddr, pos_in_page, val);
break;
case FUTEX_FD:
/* non-zero val means F_SETOWN(getpid()) & F_SETSIG(val) */
- ret = futex_fd(uaddr, pos_in_page, val);
+ ret = futex_fd (uaddr, pos_in_page, val);
break;
default:
ret = -EINVAL;
--
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my fault]
^ permalink raw reply
* Re: Arctic-2 MTD driver
From: David Gibson @ 2002-12-17 4:16 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20021216144349.GG6095@opus.bloom.county>
On Mon, Dec 16, 2002 at 07:43:49AM -0700, Tom Rini wrote:
>
> On Mon, Dec 16, 2002 at 01:09:22PM +1100, David Gibson wrote:
>
> > Having committed the core support code for the Arctic-2, here come
> > some drivers for it. Below is an MTD map for the Arctic-2, derived
> > from beech-mtd.c. Essentially all it does is provide suitable
> > hardwired partitions.
> >
> > Again, any comments before I commit this?
>
> Only that it reminded me that drivers/mtd/maps/Config.in needs some
> cleanups for PPC32, I'll be commiting those momentarily. But other than
> that, it looks fine.
Ok, updated for your changes, and committed.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [PATCH] Priority-based real-time futexes v1.0 for 2.5.52
From: Inaky Perez-Gonzalez @ 2002-12-17 4:18 UTC (permalink / raw)
To: linux-kernel, mingo, pwaechtler
This patch extracts some of the stuff that Ingo uses for the O(1)
scheduler and makes it avalable in linux/prioarray.h, so that it
can be used by other parts of the kernel.
It's main use right now is by the pfutex patch, that implements
priority based futexes.
Caveats:
- Ugly kludge in sched.h to include prioarray.h ...
Enjoy
This patch requires linux-2.5.52
diff -u /dev/null include/linux/prioarray.h:1.1.2.1
--- /dev/null Mon Dec 16 19:01:38 2002
+++ include/linux/prioarray.h Wed Dec 11 12:44:33 2002
@@ -0,0 +1,57 @@
+/*
+ * O(1) priority arrays
+ *
+ * Modified from code (C) 2002 Ingo Molnar <mingo@redhat.com> in
+ * sched.c by Iñaky Pérez-González <inaky.perez-gonzalez@intel.com> so
+ * that other parts of the kernel can use the same constructs.
+ */
+
+#ifndef _LINUX_PRIOARRAY_
+#define _LINUX_PRIOARRAY_
+
+ /* This inclusion is kind of recursive ... hmmm */
+
+#include <linux/sched.h>
+
+struct prio_array {
+ int nr_active;
+ unsigned long bitmap[BITMAP_SIZE];
+ struct list_head queue[MAX_PRIO];
+};
+
+typedef struct prio_array prio_array_t;
+
+static inline
+void pa_init (prio_array_t *array)
+{
+ unsigned cnt;
+ array->nr_active = 0;
+ memset (array->bitmap, 0, sizeof (array->bitmap));
+ for (cnt = 0; cnt < MAX_PRIO; cnt++)
+ INIT_LIST_HEAD (&array->queue[cnt]);
+}
+
+/*
+ * Adding/removing a node to/from a priority array:
+ */
+
+static inline
+void pa_dequeue (struct list_head *p, unsigned prio, prio_array_t *array)
+{
+ array->nr_active--;
+ list_del(p);
+ if (list_empty(array->queue + prio))
+ __clear_bit(prio, array->bitmap);
+}
+
+static inline
+void pa_enqueue (struct list_head *p, unsigned prio, prio_array_t *array)
+{
+ list_add_tail(p, array->queue + prio);
+ __set_bit(prio, array->bitmap);
+ array->nr_active++;
+}
+
+
+
+#endif /* #ifndef _LINUX_PRIOARRAY_ */
diff -u include/linux/sched.h:1.1.1.8 include/linux/sched.h:1.1.1.1.2.3
--- include/linux/sched.h:1.1.1.8 Mon Dec 16 18:44:32 2002
+++ include/linux/sched.h Mon Dec 16 18:52:49 2002
@@ -249,6 +249,9 @@
#define MAX_RT_PRIO MAX_USER_RT_PRIO
#define MAX_PRIO (MAX_RT_PRIO + 40)
+#define BITMAP_SIZE ((((MAX_PRIO+1+7)/8)+sizeof(long)-1)/sizeof(long))
+
+#include <linux/prioarray.h> /* Okay, this is ugly, but needs MAX_PRIO */
/*
* Some day this will be a full-fledged user tracking system..
@@ -273,7 +276,6 @@
extern struct user_struct root_user;
#define INIT_USER (&root_user)
-typedef struct prio_array prio_array_t;
struct backing_dev_info;
struct task_struct {
diff -u kernel/sched.c:1.1.1.6 kernel/sched.c:1.1.1.1.2.2
--- kernel/sched.c:1.1.1.6 Wed Dec 11 11:13:36 2002
+++ kernel/sched.c Wed Dec 11 13:28:03 2002
@@ -129,15 +129,8 @@
* These are the runqueue data structures:
*/
-#define BITMAP_SIZE ((((MAX_PRIO+1+7)/8)+sizeof(long)-1)/sizeof(long))
-
typedef struct runqueue runqueue_t;
-struct prio_array {
- int nr_active;
- unsigned long bitmap[BITMAP_SIZE];
- struct list_head queue[MAX_PRIO];
-};
/*
* This is the main, per-CPU runqueue data structure.
@@ -226,17 +219,12 @@
*/
static inline void dequeue_task(struct task_struct *p, prio_array_t *array)
{
- array->nr_active--;
- list_del(&p->run_list);
- if (list_empty(array->queue + p->prio))
- __clear_bit(p->prio, array->bitmap);
+ pa_dequeue (&p->run_list, p->prio, array);
}
static inline void enqueue_task(struct task_struct *p, prio_array_t *array)
{
- list_add_tail(&p->run_list, array->queue + p->prio);
- __set_bit(p->prio, array->bitmap);
- array->nr_active++;
+ pa_enqueue (&p->run_list, p->prio, array);
p->array = array;
}
--
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my fault]
^ permalink raw reply
* RE: [BENCHMARK]Unixbench result for kernel 2.5.52 with mm1 patch
From: Sowmya Adiga @ 2002-12-17 4:18 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <001a01c2a582$aa4f2400$6009720a@wipro.com>
Hi,
Here are the Unixbench result for kernel 2.5.52 with mm1 patch. kernel
2.5.52 with mm1 patch had drop in performance in file copy
operation,when compared with kernel
2.5.52__________________________________________________________________
Test Machine details
---------------------
processor : 0(single processor)
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 10
cpu MHz : 868.275
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse bogomips : 1716.22
-----------------------------------------------------------------------
kernel 2.5.52 with mm1
-----------------------------------------------------------------------
BYTE UNIX Benchmarks (Version 4.1.0)
System -- Linux access1 2.5.52 #5 Mon Dec 16 15:33:48 IST 2002 i686
unknown Start Benchmark Run: Mon Dec 16 16:50:46 IST 2002 1 interactive
users. 4:50pm up 1 min, 1 user, load average: 0.23, 0.09, 0.03
lrwxrwxrwx 1 root root 4 Oct 22 00:35 /bin/sh -> bash
/bin/sh: symbolic link to bash
/dev/hda2 8262068 3702376 4139996 48% /data
Dhrystone 2 using register variables 1752939.3lps (10.0 secs,10
samples)
Double-Precision Whetstone 477.1 MWIPS (10.0 secs,10
samples)
System Call Overhead 464185.6lps (10.0 secs,10
samples)
Pipe Throughput 446029.4lps (10.0 secs,10
samples)
Pipe-based Context Switching 222769.0lps (10.0 secs,10
samples)
Process Creation 4319.8 lps (30.0 secs, 3
samples)
Execl Throughput 921.1 lps (29.7 secs, 3
samples)
File Read 1024 bufsize 2000 maxblocks 243106.0KBps (30.0 secs, 3
samples)
File Write 1024 bufsize 2000 maxblocks 97288.0KBps (30.0 secs, 3
samples)
File Copy 1024 bufsize 2000 maxblocks 68153.0KBps (30.0 secs, 3
samples)
File Read 256 bufsize 500 maxblocks 112186.0KBps (30.0 secs, 3
samples)
File Write 256 bufsize 500 maxblocks 53099.0KBps (30.0 secs, 3
samples)
File Copy 256 bufsize 500 maxblocks 33800.0KBps (30.0 secs, 3
samples)
File Read 4096 bufsize 8000 maxblocks 335995.0KBps (30.0 secs, 3
samples)
File Write 4096 bufsize 8000 maxblocks 125866.0KBps (30.0 secs, 3
samples)
File Copy 4096 bufsize 8000 maxblocks 89049.0KBps (30.0 secs, 3
samples)
Shell Scripts (1 concurrent) 871.0 lpm (60.0 secs, 3
samples)
Shell Scripts (8 concurrent) 114.0 lpm (60.0 secs, 3
samples)
Shell Scripts (16 concurrent) 57.0 lpm (60.0 secs, 3
samples)
Arithmetic Test (type = short) 208197.8 lps (10.0 secs, 3
samples)
Arithmetic Test (type = int) 225191.0 lps (10.0 secs, 3
samples)
Arithmetic Test (type = long) 225183.4 lps (10.0 secs, 3
samples)
Arithmetic Test (type = float) 227478.4 lps (10.0 secs, 3
samples)
Arithmetic Test (type = double) 227482.6 lps (10.0 secs, 3
samples)
Arithoh 3997626.4 lps(10.0 secs, 3
samples)
C Compiler Throughput 408.7 lpm (60.0 secs, 3
samples)
Dc: sqrt(2) to 99 decimal places 33040.9 lpm (30.0 secs, 3
samples)
Recursion Test--Tower of Hanoi 29275.1 lps (20.0 secs, 3
samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 1752939.3 150.2
Double-Precision Whetstone 55.0 477.1 86.7
Execl Throughput 43.0 921.1 214.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 68153.0 172.1
File Copy 256 bufsize 500 maxblocks 1655.0 33800.0 204.2
File Copy 4096 bufsize 8000 maxblocks 5800.0 89049.0 153.5
Pipe Throughput 12440.0 446029.4 358.5
Process Creation 126.0 4319.8 342.8
Shell Scripts (8 concurrent) 6.0 114.0 190.0
System Call Overhead 15000.0 464185.6 309.5
=========
FINAL SCORE 201.2
------------------------------------------------------------------------
kernel 2.5.52
------------------------------------------------------------------------
BYTE UNIX Benchmarks (Version 4.1.0)
System -- Linux access1 2.5.52 #4 Mon Dec 16 10:16:06 IST 2002 i686
unknown Start Benchmark Run: Mon Dec 16 11:30:24 IST 2002 1 interactive
users. 11:30am up 1:05, 1 user, load average: 0.07, 0.58, 0.79
lrwxrwxrwx 1 root root 4 Oct 22 00:35 /bin/sh -> bash
/bin/sh: symbolic link to bash
/dev/hda2 8262068 3454348 4388024 45% /data
Dhrystone 2 using register variables 1753628.8lps (10.0 secs,10
samples)
Double-Precision Whetstone 476.9 MWIPS (10.0 secs,10
samples)
System Call Overhead 450934.1lps (10.0 secs,10
samples)
Pipe Throughput 456612.8lps (10.0 secs,10
samples)
Pipe-based Context Switching 225683.4lps (10.0 secs,10
samples)
Process Creation 4275.6 lps (30.0 secs, 3
samples)
Execl Throughput 909.8 lps(29.7 secs,3 samples)
File Read 1024 bufsize 2000 maxblocks 244385.0KBps (30.0 secs, 3
samples)
File Write 1024 bufsize 2000 maxblocks 100577.0KBps (30.0
secs, 3 samples)
File Copy 1024 bufsize 2000 maxblocks 70152.0KBps (30.0 secs, 3
samples)
File Read 256 bufsize 500 maxblocks 111926.0KBps (30.0 secs, 3
samples)
File Write 256 bufsize 500 maxblocks 56243.0KBps (30.0 secs, 3
samples)
File Copy 256 bufsize 500 maxblocks 35585.0KBps (30.0 secs, 3
samples)
File Read 4096 bufsize 8000 maxblocks 338086.0KBps (30.0 secs, 3
samples)
File Write 4096 bufsize 8000 maxblocks 126577.0KBps (30.0 secs, 3
samples)
File Copy 4096 bufsize 8000 maxblocks 89815.0KBps (30.0 secs, 3
samples)
Shell Scripts (1 concurrent) 849.1 lpm (60.0 secs, 3
samples)
Shell Scripts (8 concurrent) 111.0 lpm (60.0 secs, 3
samples)
Shell Scripts (16 concurrent) 56.0 lpm (60.0 secs, 3
samples)
Arithmetic Test (type = short) 208275.8 lps (10.0 secs, 3
samples)
Arithmetic Test (type = int) 225111.9 lps (10.0 secs, 3
samples)
Arithmetic Test (type = long) 225305.4 lps (10.0 secs, 3
samples)
Arithmetic Test (type = float) 227632.9 lps (10.0 secs, 3
samples)
Arithmetic Test (type = double) 227629.5 lps (10.0 secs, 3
samples)
Arithoh 3997619.3lps (10.0 secs, 3
samples)
C Compiler Throughput 408.0 lpm (60.0 secs, 3
samples)
Dc: sqrt(2) to 99 decimal places 32839.0 lpm (30.0 secs, 3
samples)
Recursion Test--Tower of Hanoi 29277.5 lps (20.0 secs, 3
samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 1753628.8 150.3
Double-Precision Whetstone 55.0 476.9 86.7
Execl Throughput 43.0 909.8 211.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 70152.0 177.2
File Copy 256 bufsize 500 maxblocks 1655.0 35585.0 215.0
File Copy 4096 bufsize 8000 maxblocks 5800.0 89815.0 154.9
Pipe Throughput 12440.0 456612.8 367.1
Process Creation 126.0 4275.6 339.3
Shell Scripts (8 concurrent) 6.0 111.0 185.0
System Call Overhead 15000.0 450934.1 300.6
=========
FINAL SCORE 201.9
------------------------------------------------------------------------
Regards
Sowmya Adiga
Project Engineer
Wipro Technologies
53/1,Hosur Road,Madivala
Bangalore-560 068,INDIA
Tel: +91-80-5502001 Extn.5086
sowmya.adiga@wipro.com
^ permalink raw reply
* Re: [LARTC] total bandwidth ocupied
From: Adi Nugroho @ 2002-12-17 4:12 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104000531807331@msgid-missing>
Pada hari Selasa, 17 Desember 2002 01:06, Catalin Bucur menulis:
> | * how to make the bandwidth are limited exacly at "x" kbps?
>
> Set a lower value for ceil and a value for cburst thus:
> ceil+cburst=limited_bandwidth
Thank you very much.
This calculation is very helpfull.
--
Salam,
Adi Nugroho
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ 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.