* Re: 2.4.5-ac16 -- Still getting unresolved gameport_register_port and gameport_unregister_port symbols in joystick drivers.
From: Keith Owens @ 2001-06-21 4:54 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel, Vojtech Pavlik
In-Reply-To: <web-26144619@back1.mail.megapathdsl.net>
On Wed, 20 Jun 2001 16:38:03 -0700,
Miles Lane <miles@megapathdsl.net> wrote:
>depmod: *** Unresolved symbols in /lib/modules/2.4.5-ac16/kernel/drivers/char/joystick/cs461x.o
>depmod: gameport_register_port
Quick and dirty fix.
Index: 5.39/drivers/char/joystick/Config.in
--- 5.39/drivers/char/joystick/Config.in Wed, 20 Jun 2001 13:07:10 +1000 kaos (linux-2.4/Y/b/35_Config.in 1.1.1.4 644)
+++ 5.39(w)/drivers/char/joystick/Config.in Thu, 21 Jun 2001 14:47:53 +1000 kaos (linux-2.4/Y/b/35_Config.in 1.1.1.4 644)
@@ -6,7 +6,7 @@ mainmenu_option next_comment
comment 'Joysticks'
if [ "$CONFIG_INPUT" != "n" ]; then
- tristate 'Game port support' CONFIG_INPUT_GAMEPORT
+ dep_tristate 'Game port support' CONFIG_INPUT_GAMEPORT $CONFIG_INPUT
dep_tristate ' Classic ISA/PnP gameports' CONFIG_INPUT_NS558 $CONFIG_INPUT_GAMEPORT
dep_tristate ' PDPI Lightning 4 gamecard' CONFIG_INPUT_LIGHTNING $CONFIG_INPUT_GAMEPORT
dep_tristate ' Aureal Vortex and Trident 4DWave gameports' CONFIG_INPUT_PCIGAME $CONFIG_INPUT_GAMEPORT
There are too many cross directory dependencies and undocumented
assumptions on input, gameport, joystick and sound options. Vojtech,
we need a specification on how these should interact before we make any
more changes to the config code. What should the dependencies be for
input, gameport, joysticks and gameport using soundcard really be?
^ permalink raw reply
* Re: [OT] Threads, inelegance, and Java
From: Dan Kegel @ 2001-06-21 4:10 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Russell Leighton wrote:
> The lack of a good operating system _dependent_ interface
> makes running fast hard in Java when you need to do IO...
> yes, there is always JNI so you can add a little C to mmap a file or whatever,
JDK 1.4 beta comes with a way to memory-map files, and various
other I/O improvements (like poll(); see http://www.jcp.org/jsr/detail/51.jsp).
Chris Smith will have some nio benchmarks up on http://www.jlinux.org/
next week or so showing how well their nonblocking network I/O performs.
Sun is slowly getting their act together on the I/O front with java.
Still, the competition from C# and for that matter gcj will probably be
a good thing, keep 'em on their toes.
(Disclaimer: I served on the JSR-51 expert group, representing the linux
point of view, kinda.)
- Dan
^ permalink raw reply
* [PATCH] Avoid !__GFP_IO allocations to eat from memory reservations
From: Marcelo Tosatti @ 2001-06-21 2:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml, linux-mm
Linus,
I just read pre3<->pre4 diff and it seems you missed this patch... here it
goes again.
In pre3/4, GFP_BUFFER allocations can eat from the "emergency" memory
reservations in case try_to_free_pages() fails for those allocations in
__alloc_pages().
Here goes the (tested) patch to fix that:
--- linux/mm/page_alloc.c.orig Thu Jun 14 11:00:14 2001
+++ linux/mm/page_alloc.c Thu Jun 14 11:32:56 2001
@@ -453,6 +453,12 @@
int progress = try_to_free_pages(gfp_mask);
if (progress || gfp_mask & __GFP_IO)
goto try_again;
+ /*
+ * Fail in case no progress was made and the
+ * allocation may not be able to block on IO.
+ */
+ else
+ return NULL;
}
}
}
^ permalink raw reply
* Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
From: David S. Miller @ 2001-06-21 3:44 UTC (permalink / raw)
To: Zack Weinberg; +Cc: linux-kernel, torvalds
In-Reply-To: <20010620202621.C12387@stanford.edu>
Zack Weinberg writes:
> Linus Torvalds wrote:
> > And before you say "it has to return EFAULT", check the standards, and
> > think about the case of libraries vs system calls - and how do you tell
> > them apart?
>
> My reading of the standard is that it has to either return EFAULT or
^^
> raise SIGSEGV. But I am not expert in XPG4-ese.
Linus is trying to point out: "what is this 'it'?" Is it glibc or
what the kernel gives you?
> Whether or not the standard requires anything, I would much rather
> that the kernel not silently discard error conditions.
But only perhaps from a "quality of implementation" perspective not a
"correctness" one.
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply
* Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
From: Zack Weinberg @ 2001-06-21 3:26 UTC (permalink / raw)
To: linux-kernel, torvalds
Linus Torvalds wrote:
> If somebody passes in a bad pointer to a system call, you've just
> invoced the rule of "the kernel _may_ be nice to you, but the kernel
> might just consider you a moron and tell you it worked".
>
> There is no "lost data" or anything else. You've screwed yourself, and
> you threw the data away. Don't blame the kernel.
>
> And before you say "it has to return EFAULT", check the standards, and
> think about the case of libraries vs system calls - and how do you tell
> them apart?
My reading of the standard is that it has to either return EFAULT or
raise SIGSEGV. But I am not expert in XPG4-ese.
Whether or not the standard requires anything, I would much rather
that the kernel not silently discard error conditions.
zw
^ permalink raw reply
* Re: [OT] Threads, inelegance, and Java
From: Pete Zaitcev @ 2001-06-21 3:13 UTC (permalink / raw)
To: landley; +Cc: linux-kernel
In-Reply-To: <mailman.993083762.1429.linux-kernel2news@redhat.com>
> Then again JavaOS was an abortion on top of Slowaris. [...]
This is a false statemenet, Rob. It was an abortion, all right,
but not related to Solaris in any way at all.
JavaOS existed in two flavours minimum, which had very little
in common. The historically first of them (Luna), was a home-made
executive with pretty rudimentary abilities. I must admit I am
not intimately familiar with its genesis. A part of it was related
to the JavaOS running on Sun 701 chip, but what came first,
I cannot tell. Second flavour of JavaOS was made on top of
Chorus, and, _I think_, used large parts of Luna in the the
JVM department, but it had decent kernel, with such novations
as a device driver interface :)
> make a DPMI DOS port with an SVGA AWT and say "hey, we're done, and it boots
> off a single floppy", I'll never know.
Such a thing existed. I do not remember its proper name,
but I remember that it booted from hard disk. Floppy
was too small for it.
> Porting half of Solaris to Power PC for JavaOS has got to be one of the most
> peverse things I've seen in my professional career.
I never heard of PPC port of either of JavaOSes, although
Chorus runs on PPC. Perhaps this is what you mean.
Solaris for PPC existed, but never was widespread.
It did not have JVM bundled.
> I'm upset that Red Hat 7.1 won't install on that old laptop because it only
> has 24 megs of ram and RedHat won't install in that. [...]
You blew adding a swap partition, I suspect...
-- Pete
^ permalink raw reply
* Re: How to compile on one machine and install on another?
From: Keith Owens @ 2001-06-21 3:10 UTC (permalink / raw)
To: Maciek Nowacki; +Cc: Tom Diehl, linux-kernel
In-Reply-To: <20010620141119.A5660@wintermute.starfire>
On Wed, 20 Jun 2001 14:11:20 -0600,
Maciek Nowacki <maciek@Voyager.powersurfr.com> wrote:
>Change MODLIB in $(TOPDIR)/Makefile (e.g. /usr/src/linux/Makefile). I do this
>to compile the kernel and modules without root priviledges at all. make
>modules_install will fail at the end when trying to run 'depmod', but that's
>okay - you can do that yourself:
That is not OK, it requires user hacks and causes errors. Use
make INSTALL_MOD_PATH=foo modules_install
and everything works. Create $(INSTALL_MOD_PATH)/lib/modules first.
^ permalink raw reply
* Re: aic7xxx oops with 2.4.5-ac13
From: Jeff V. Merkey @ 2001-06-21 4:06 UTC (permalink / raw)
To: Trevor Hemsley; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20010621010814Z264340-17720+6179@vger.kernel.org>
On Thu, Jun 21, 2001 at 02:08:17AM +0000, Trevor Hemsley wrote:
Ditto. I am also seeing this oops calling the sg driver for a
robotic tape library, and it also seems to happen on 2.4.4.
Jeff
> Just upgraded from 2.4.3 to 2.4.5-ac13 and get an aiee, killing interrupt
> handler on boot as aic7xxx.o is loaded. I have an Adaptec 2906 PCI card
> with a Nikon CoolscanIII and an HP optical drive attached. Works ok on
> aic7xxx_old. Works with an initial bus reset on 2.4.3. Dies a horrible death
> on 2.4.5-ac13.
>
> trevor@trevor4:/tmp > /sbin/lspci
> 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
> 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
> 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
> 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
> 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
> 00:09.0 SCSI storage controller: Adaptec AHA-7850 (rev 03)
> 00:0a.0 SCSI storage controller: Initio Corporation 360P (rev 02)
> 00:0b.0 Network controller: Compaq Computer Corporation Netelligent 10/100 (rev 10)
> 00:0c.0 Ethernet controller: 3Com Corporation 3c900 Combo [Boomerang]
> 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01)
>
> On 2.4.3 I get the following errors when aic7xxx loads
>
> ahc_pci:0:9:0: WARNING no command for scb 0 (cmdcmplt)
> QOUTPOS = 0
> scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5
> <Adaptec 2902/04/10/15/20/30C SCSI adapter>
> aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs
>
> scsi1:0:2:0: Attempting to queue an ABORT message
> (scsi1:A:2:0): Queuing a recovery SCB
> scsi1:0:2:0: Device is disconnected, re-queuing SCB
> Recovery code sleeping
> (scsi1:A:2:0): Abort Message Sent
> (scsi1:A:2:0): SCB 3 - Abort Completed.
> Recovery SCB completes
> Recovery code awake
> aic7xxx_abort returns 8194
>
> It then carries on and works.
>
> Ksymoops output follows but may not be entirely reliable
> because it's from a hand written file and /proc/ksyms and /proc/modules are
> from 2.4.3.
> trevor@trevor4:/tmp > more decoded-245-ksymoops
> ksymoops 2.4.0 on i686 2.4.3. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.4.5-ac13/ (specified)
> -m /l243/System.map-2.4.5-ac13 (specified)
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> c018d250
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<c018d250>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010057
> eax: 00000000 ebx: 00000012 ecx: 00000001 edx: 00000000
> esi: ffffffff edi: d74f0600 ebp: 00000000 esp: c0233dc0
> ds: 0018 es: 0018 ss: 0018
> Process swapper (pid 0, stackpage=c0233000)
> Stack: d9133058 00000000 00000000 00000012 00000000 d74f0600 00000000 414f0600
> d74f0600 00000001 00000001 d91356ee d74f0600 d74f0690 00000000 00000000
> 00000003 d913e18f d74f0600 00000012 00000000 d74f0600 00000000 00000010
> Call Trace: [<d9133058>] [<d91356ee>] [<d913e18f>] [<d913e4fd>] [<d913e539>]
> [<c0115b98>] [<c0110000>] [<d9136b89>] [<e6948262>] [<c019c9a2>] [<c011c635>]
> [<d9132ad4>] [<c0108301>] [<c01084e6>] [<c0105160>] [<c0105160>] [<c010a82e>]
> [<c0105160>] [<c0105160>] [<c0100018>] [<c010518d>] [<c01051f2>] [<c0105000>]
> [<c01001cf>]
> Code: 8b 40 04 85 c0 74 15 3b 90 6c 00 00 00 75 07 80 88 fc 00 00
>
> >>EIP; c018d250 <scsi_report_bus_reset+8/28> <=====
> Trace; d9133058 <[serial].bss.end+18d5/18dd>
> Trace; d91356ee <[aic7xxx]ahc_filter_command+20a/2a4>
> Trace; d913e18f <[aic7xxx]ahc_reset+37/470>
> Trace; d913e4fd <[aic7xxx]ahc_reset+3a5/470>
> Trace; d913e539 <[aic7xxx]ahc_reset+3e1/470>
> Trace; c0115b98 <release_console_sem+94/98>
> Trace; c0110000 <mtrr_close+34/c8>
> Trace; d9136b89 <[aic7xxx]ahc_pci_map_registers+1c5/254>
> Trace; e6948262 <END_OF_CODE+d78b186/????>
> Trace; c019c9a2 <cursor_timer_handler+22/28>
> Trace; c011c635 <timer_bh+259/2b0>
> Trace; d9132ad4 <[serial].bss.end+1351/18dd>
> Trace; c0108301 <handle_IRQ_event+4d/78>
> Trace; c01084e6 <do_IRQ+a6/f4>
> Trace; c0105160 <default_idle+0/34>
> Trace; c0105160 <default_idle+0/34>
> Trace; c010a82e <call_do_IRQ+5/b>
> Trace; c0105160 <default_idle+0/34>
> Trace; c0105160 <default_idle+0/34>
> Trace; c0100018 <startup_32+18/cb>
> Trace; c010518d <default_idle+2d/34>
> Trace; c01051f2 <cpu_idle+3e/54>
> Trace; c0105000 <prepare_namespace+0/8>
> Trace; c01001cf <L6+0/2>
> Code; c018d250 <scsi_report_bus_reset+8/28>
> 00000000 <_EIP>:
> Code; c018d250 <scsi_report_bus_reset+8/28> <=====
> 0: 8b 40 04 mov 0x4(%eax),%eax <=====
> Code; c018d253 <scsi_report_bus_reset+b/28>
> 3: 85 c0 test %eax,%eax
> Code; c018d255 <scsi_report_bus_reset+d/28>
> 5: 74 15 je 1c <_EIP+0x1c> c018d26c <scsi_report_bus_reset+24/28>
> Code; c018d257 <scsi_report_bus_reset+f/28>
> 7: 3b 90 6c 00 00 00 cmp 0x6c(%eax),%edx
> Code; c018d25d <scsi_report_bus_reset+15/28>
> d: 75 07 jne 16 <_EIP+0x16> c018d266 <scsi_report_bus_reset+1e/28>
> Code; c018d25f <scsi_report_bus_reset+17/28>
> f: 80 88 fc 00 00 00 00 orb $0x0,0xfc(%eax)
>
> <0> Kernel panic: Aiee, killing interrupt handler!
>
> 1070 warnings issued. Results may not be reliable.
>
>
> Trevor Hemsley, Brighton, UK.
> Trevor-Hemsley@dial.pipex.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: Why use threads ( was: Alan Cox quote?)
From: David Schwartz @ 2001-06-21 2:43 UTC (permalink / raw)
To: Davide Libenzi; +Cc: linux-kernel
In-Reply-To: <XFMail.20010620192245.davidel@xmailserver.org>
> Just to summarize :
> 1) You said to handle 16000 sessions with 10 threads
> 2) I said: "Humm, you've to select() about 1600 fds ..."
> 3) You said : "Who said anything about 'select'?"
You can use any I/O model you want. I've suggested several.
> The stuff above looks like select() to me.
I'm not sure what that has to do with anything.
> About the scale factor of select()/poll() my agreement is only partial.
> Have You ecer observed that Your processes tend to become a bit
> CPU bound when
> stocking a lot of fds inside a poll ?
Okay, let's compare two servers.
Server one is handling 10 file descriptors. The cost of a single call to
poll is 3 microseconds. Assume that the server is coded to get back to
'poll' as quickly as it can, but due to load the code manages to call 'poll'
every 100 microseconds, so the overhead of poll is 3% of the available CPU.
Now server two, with identical hardware and software, is handling 10,000
file descriptors. The cost of a single call to poll is now 3,000
microseconds (assuming 'poll' scales linearly, it actually scales slightly
better than linearly). Since this code is 1,000 times busier, assume it gets
around to calling 'poll' every 100,000 microseconds. Note that, percentage
wise, the overhead of poll is the same, 3%.
It is actually even better than this. For one thing, in the second case,
the less-frequent calls to poll mean that you do more I/O per poll call per
connection, because there is more time in between calls to 'recv' for data
to go into the buffers. This also means more 'full reads' and fewer 'partial
reads' which improves your buffer handling signifantly. Same is true for
your 'write' calls, the less often you call 'write' the more often
(percentage wise) you'll write all you tried to write.
Now this assumes no clever tricks to improve poll's scalability. This
doesn't even consider the fact that calling 'poll' less often means that a
higher percentage of sockets will be discovered per call to poll.
Again, the problems with select/poll are not about scalability, they're
about performance (in terms of absolute CPU consumption) at low load levels
with large numbers of file descriptors.
In contrast, if you had 1,600 execution vehicles instead of 10, you would
suffer more context switches, more memory overhead for stacks, and you would
incur one kernel/user transition for each socket discovered instead of far
fewer. In addition, a much higher percentage of your I/O operations would
block, and blocking operations are more expensive than those that don't
result in a block.
DS
^ permalink raw reply
* Re: How to compile on one machine and install on another?
From: Keith Owens @ 2001-06-21 2:42 UTC (permalink / raw)
To: Helge Hafting; +Cc: McHarry, John, linux-kernel
In-Reply-To: <3B3057BE.4374D4B2@idb.hist.no>
On Wed, 20 Jun 2001 09:58:54 +0200,
Helge Hafting <helgehaf@idb.hist.no> wrote:
>This is enough if you don't use modules. If you use modules you
>need to copy them too, which is trickier. Several good methods
>have been demonstrated, here is another if you can't use the nfs
>approach:
>
>1. If you are running the same kernel revision on the compile machine,
> temporarily rename /lib/modules/<version> to something else.
> Yes - this could be dangerous but tend to work well on a "home
>machine"
>2. Do the "make modules_install" on the compile machine.
The correct way of installing for a target machine is to use
make INSTALL_MOD_PATH=foo modules_install
You need to mkdir -p foo/lib/modules first. Everything is installed in
foo/lib/modules/`uname -r` instead of /lib/modules so you do not
disturb your compile system.
There is also make INSTALL_PATH to specify where vmlinuz and System.map
are stored for make zlilo and make install.
^ permalink raw reply
* Re: is there a linux running on jvm arch ?
From: Jeff Dike @ 2001-06-21 3:50 UTC (permalink / raw)
To: FORT David; +Cc: LKML
In-Reply-To: <3B311519.3090401@free.fr>
popo.enlighted@free.fr said:
> I'm dreaming of a linux booting in a browser applet(imagine sending
> such thing in a mail to MS peoples !!!!)
If you really want to help the MS peoples get Linux, consider a straight port
of UML to Windows.
I've been trying to encourage someone to do this for a while, with limited
success :-( Enough has been done that I think I know what the main obstacles
are, and I think I know that it's possible.
So, if you're interested (and have the appropriate Win-fu) let me know, and
grab the code and start porting...
Jeff
^ permalink raw reply
* Re: [linux-lvm] Re: another nice feature for packagers ...
From: Steven Lembark @ 2001-06-21 2:29 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20010618103116.A32391@sistina.com>
>> It would be nice if --prefix worked consistently for the new release.
>> Until some final kinks in devfs get worked over keeping the VG's out of
>> /dev without having to hack the source code would be helpful.
>
> Care to explain further? I don't know what you're talking about here.
> --prefix works fine for me in all cases.
Try:
./configure --prefix=/lvm;
build and install everything. Notice where the vgXX directories go: /dev,
not /lvm. None of the configure switches (last time I compiled) were able
to keep the vg's out of devfs's clutches w/o hacking a #define in the code.
As a temporary fix until all the devfs glitches are worked out (some not lvm
related) it'd be nice to avoid problems.
^ permalink raw reply
* Re: [LARTC] 150.150. addresses
From: Tomasz Orzechowski @ 2001-06-21 2:27 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-99309192123806@msgid-missing>
adelphia wrote on Wed, Jun 20, 2001 at 10:24:18PM -0400:
> Are 150.150.*.* adresses private or reserve addresses?
> My friend has a one, and I tried doing an nslookup, ping, and traceroute
> with no luck.
$ whois -h whois.arin.net 150.150.1.1
LG-EDS Systems Inc. (NET-LGEDS-NET)
555 Hogae-Dong,Dongan-Gu
AnYang-Si KyungKi-Do 430-080
KR
Netname: LGEDS-NET
Netblock: 150.150.0.0 - 150.150.255.255
gw5#sh ip bgp 150.150.1.1
BGP routing table entry for 150.150.0.0/16, version 1869114
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
701 2828 3786 6068
157.130.96.149 from 157.130.96.149 (137.39.2.106)
Origin IGP, localpref 100, valid, external
2548 3786 6068
209.49.240.185 (metric 20) from 209.221.31.9 (209.221.31.9)
Origin IGP, metric 720501, localpref 100, valid, internal, best
why ask here? :-)
--
Tomasz Orzechowski tmo@apk.net
APK.net systems administration team TO630
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
^ permalink raw reply
* [LARTC] 150.150. addresses
From: adelphia @ 2001-06-21 2:24 UTC (permalink / raw)
To: lartc
Are 150.150.*.* adresses private or reserve addresses?
My friend has a one, and I tried doing an nslookup, ping, and traceroute
with no luck.
Thanks
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
^ permalink raw reply
* USB Device Support
From: Darryl Dieckman @ 2001-06-21 2:25 UTC (permalink / raw)
To: linux-mtd
Hello,
I'm looking into the feasibility of developing a driver for a USB
FLASH storage device. The MTD project page says that a goal
of the project is to allow device developers to write read, write,
and erase functions for their particular device, and you'll be ready
to go. Has the project evolved to a state where this is indeed a 'simple'
exercise?
As for the magnitude of this 'simple' task, would you say that it
would be a 1 week or 1 month exercise for an experienced
programmer. By experienced I mean experienced in C and
Linux, but not an experienced kernel developer.
I'm also under the impression that by creating this driver, I will also
get support for the Journaling Flash File System. Is this a correct
assumption?
Thanks in advance for any inputs on this endeavor. Hopefully all
will go well, and I will soon be able to add another device to the
list. ;)
Thanks
Darryl
Darryl Dieckman ddieckma@cliftonlabs.com
Senior Software Engineer http://www.cliftonlabs.com
Clifton Labs, Inc. Cincinnati, Ohio
pgp key available
^ permalink raw reply
* RE: Why use threads ( was: Alan Cox quote?)
From: Davide Libenzi @ 2001-06-21 2:22 UTC (permalink / raw)
To: David Schwartz; +Cc: linux-kernel
In-Reply-To: <NCBBLIEPOCNJOAEKBEAKMEOLPPAA.davids@webmaster.com>
On 21-Jun-2001 David Schwartz wrote:
>
>> > Who said anything about 'select'? If you want to learn
>> > how to write
>> > efficient multi-threaded servers, take a course or read a book.
>> > Heck, you
>> > can even ask me questions on marginally appropriate lists or
>> > even by private
>> > email. But don't put words in my mouth.
>
>> I was just thinking about having a course on how to write mt applications,
>> are You currently keeping such courses ?
>
> I've been preparing one for several years, but due to the constantly
> changing state of the art and the other limitations on my time, it just
> keeps getting further behind.
>
>> Is still this Your address :
>>
>> David Schwartz
>> 16000 NW Modesty Dr
>
> That was never my address, though I lived at 16000 NW 1st street a long
> time ago.
>
>> How do you handle an average of 1600 sessions over a single
>> process without
>> using select()/poll(), I'm just curious ?
>
> Well, with 1,600 connections, things are pretty easy. This is so far
below
> the limit of modern machines that efficiency only matters if your server is
> just one of many things the machine does. I would just use two threads in
> poll loops, each working on half the descriptors. Some would have these
> threads actually do the I/O, others would have it queue I/O jobs to another
> pool of I/O threads that do the actual read/write operations.
>
> My (WebMaster's) library does even better than this, converting the
'poll'
> threads into 'do the I/O' threads dynamically. That way if the 'poll' only
> hits on one file descriptor, you don't have to do a context switch to
> service the I/O, but you also can get back to 'poll' pretty quickly even if
> the I/O manages to block when it's not supposed to.
>
> But 1,600 is easy, so there's no reason to sweat about it.
>
> Things get more difficult at 16,000 connections. At this level, I
recommend
> a tiered approach. Separate the file descriptors into the 80% that are 20%
> of the activity and find the 10% that are 90% of the activity. Have separate
> threads poll on each of these groups. The advantage of this is that the more
> expensive poll calls (the ones on the greatest number of file descriptors)
> are called very rarely (because those file descriptors aren't very active.
> Tracking code can move file descriptors dynamically from group to group.
>
> No matter what anyone tells you, 'poll' scales *better* than O(n) (in
other
> words, the more connections you have, the less CPU time you need per
> connection to discover which sockets need work), and since your I/O can't
> possibly scale better than O(n), poll is as scalable as it needs to be. If
> you double the number of sockets, you double the cost of 'poll' but you also
> double the amount of information you get per poll call (actually, you more
> than double it, but that's a long story).
>
> The problem with 'poll' is efficiency at *low* load. Since I write
mostly
> servers designed to operate at high load, I don't worry too much about
> efficiency at low load. The hard case for 'poll' is large numbers of file
> descriptors at very low load (so you're unlikely to find more than one
> 'active' fd at a time). Fortunately these cases don't need much efficiency.
> The operating systems max out at around 65,536 descriptors anyway, and
> keeping these inactive enough to allow such low discovery rates means a
> server with most of its CPU to spare.
>
> Not that I have anything against the more efficient I/O discovery
> techniques under discussion and development. There's nothing wrong with a
> more efficient approach, especially one that's more efficient at every
> combination of loads and socket counts. But as far as ultimate scalability
> goes, socket discovery is not the limiting factor -- far from it.
Just to summarize :
1) You said to handle 16000 sessions with 10 threads
2) I said: "Humm, you've to select() about 1600 fds ..."
3) You said : "Who said anything about 'select'?"
The stuff above looks like select() to me.
I assume You know how select is implemented inside the kernel
( file->f_op->poll() ), so I don't understand Your phrase :
<quite rude>
Who said anything about 'select'? If you want to learn how to write
efficient multi-threaded servers, take a course or read a book.
</quite rude>
About the scale factor of select()/poll() my agreement is only partial.
Have You ecer observed that Your processes tend to become a bit CPU bound when
stocking a lot of fds inside a poll ?
- Davide
^ permalink raw reply
* [PATCH] Avoid !__GFP_IO allocations to eat from memory reservations
From: Marcelo Tosatti @ 2001-06-21 2:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml, linux-mm
Linus,
I just read pre3<->pre4 diff and it seems you missed this patch... here it
goes again.
In pre3/4, GFP_BUFFER allocations can eat from the "emergency" memory
reservations in case try_to_free_pages() fails for those allocations in
__alloc_pages().
Here goes the (tested) patch to fix that:
--- linux/mm/page_alloc.c.orig Thu Jun 14 11:00:14 2001
+++ linux/mm/page_alloc.c Thu Jun 14 11:32:56 2001
@@ -453,6 +453,12 @@
int progress = try_to_free_pages(gfp_mask);
if (progress || gfp_mask & __GFP_IO)
goto try_again;
+ /*
+ * Fail in case no progress was made and the
+ * allocation may not be able to block on IO.
+ */
+ else
+ return NULL;
}
}
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* [LARTC] [diffserv] At present , TC architecture made for Diffserv on linux is wrong
From: jinho Hwang @ 2001-06-21 2:03 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]
From old times,
I have studied Diffserv and made an experiment in Linux kernel 2.4.x
but I have a question?
At first, supposed the input link capacity of diffserv's edge(ingress)
router is
more capacity than output link.
that is, total e1's input BW is 20Mbps, total e1's ouput BW is 10Mbps
s1 ---------l
10M l
l----------- e1----------e2 ------------- d1
l 10M ^ 10M 10M
s2 ----------l l
10M l
l
edge router (e1)
--------------------------
l input : output l
l part : part l
l : l
--------------------------
At second, s1 host sends AF1(2.5M), AF2(2.5M), AF3(2.5M), AF4(2.5M) -
that is , total 10M traffic - to d1 host.
s2 host sends best effort (6M) traffic to d1 host.
total sending traffic is 16M.
At this time, both the user s1, s2's traffic is not guaranteed in
existing tc architecture
because the result of s1,s2 traffic metering is not marked in the e1's
input part,
queue of e1's output has only a FIFO queue.
As this output's sch_dsmark has a FIFO queue, Best effort traffic and AF
classes traffic is combined and does not guaranteed AF classes.
Existing sch_ingress and sch_dsmark architecture in edge router(e1) is
following that...
http://dcn.ssu.ac.kr/~peniel5/zboard/zboard.php?id=diffserv
here, input device uses sch_ingress, output device uses sch_dsmark
as you see, mark of the traffic(af) is end part ( output device ) in this
picture.
Therefore, in this circumstance, I think that existing TC structure in
Linux kernel 2.4.x is not availble.
Do you have another idea?
I think wrong thing?
well.. I think I have right idea.
and.. finally,
I have a suggestion!
To solve these demerits, I made ingress marker in linux kernel 2.4.x.
that is, I take DSCP marking part 's position in input device part .
the result, architecture of these experiments and performance test
( existing architecture VS suggested architecture )
showed in my web board
my web board is
http://dcn.ssu.ac.kr/~peniel5/zboard/zboard.php?id=diffserv
I hope your opinion !!!!!
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2780 bytes --]
^ permalink raw reply
* Re: Alan Cox quote? (was: Re: accounting for threads)
From: D. Stimits @ 2001-06-21 1:57 UTC (permalink / raw)
Cc: linux-kernel
In-Reply-To: <0106201618550H.00776@localhost.localdomain>
Rob Landley wrote:
>
> On Wednesday 20 June 2001 20:42, D. Stimits wrote:
> > Rob Landley wrote:
> > ...snip...
> >
> > > The patches-linus-actuall-applies mailing list idea is based on how Linus
> > > says he works: he appends patches he likes to a file and then calls patch
> > > -p1 < thatfile after a mail reading session. It wouldn't be too much
> > > work for somebody to write a toy he could use that lets him work about
> > > the same way but forwards the messages to another folder where they can
> > > go out on an otherwise read-only list. (No extra work for Linus. This
> > > is EXTREMELY important, 'cause otherwise he'll never touch it.)
> >
> > What if the file doing patches from is actually visible on a web page?
> > Or better yet, if the patch command itself was modified such that at the
> > same time it applies a patch, the source and the results were added to a
> > MySQL server which in turn shows as a web page?
>
> His patch file already has a bunch of patches glorped together. In theory
> they could be separated again by parsing the mail headers. I suppose that
> would be less work for Linus...
>
> The point is, the difference between the patches WE get and the patches LINUS
> gets is the granularity. He's constantly extorting other people to watch the
> granularity of what they send him (small patches, each doing one thing, with
> good documentation as to what they do and why, in seperate messages), but
> what WE get is a great big diff about once a week.
If patch was itself modified, the one big patch file could easily be
considered in terms of all of its smaller patches in any processing it
does as a publication aid.
>
> So what I'm trying to figure out is if we can impose on Linus to cc: a
> mailing list on the stream of individual patch messages he's applying to his
> tree, so we can follow it better. And he IS willing to do a LITTLE work for
> us. He's issuing changelogs now. This would be significantly less effort
> than that...
The patch command already considers one large file to be a lot of
smaller patches in most cases. Why not, as it does its work, let it
document what it has done?
>
> MySQL is overkill, and since these things started as mail messages why should
> they be converted into a foriegn format? There's threaded archivers for
> mailing lists and newsgroups and stuff already, why reinvent the wheel?
MySQL is just a sample. I mention it because it is quite easy to link a
web server to. Imagine patch running on a large file that is a
conglomeration of 50 small patches; it could easily summarize this, and
storing it through MySQL adds a lot of increased web flexibility (such
as searching and sorting). It is, however, just one example of a way to
make "patch" become autodocumenting.
>
> Rob
^ permalink raw reply
* [patch] 2.4.6-pre4 unresolved symbol do_softirq
From: Keith Owens @ 2001-06-21 1:55 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
do_softirq is called from asm code which does not get preprocessed.
The label needs to be exposed so cpp can see it.
Against 2.4.6-pre4.
Index: 6-pre4.1/include/asm-i386/softirq.h
--- 6-pre4.1/include/asm-i386/softirq.h Sat, 09 Jun 2001 11:25:53 +1000 kaos (linux-2.4/T/51_softirq.h 1.3 644)
+++ 6-pre4.1(w)/include/asm-i386/softirq.h Thu, 21 Jun 2001 11:52:34 +1000 kaos (linux-2.4/T/51_softirq.h 1.3 644)
@@ -36,13 +36,13 @@ do { \
\
".section .text.lock,\"ax\";" \
"2: pushl %%eax; pushl %%ecx; pushl %%edx;" \
- "call do_softirq;" \
+ "call %c1;" \
"popl %%edx; popl %%ecx; popl %%eax;" \
"jmp 1b;" \
".previous;" \
\
: /* no output */ \
- : "r" (ptr) \
+ : "r" (ptr), "i" (do_softirq) \
/* no registers clobbered */ ); \
} while (0)
^ permalink raw reply
* Re: ip_tables/ipchains
From: Pete Toscano @ 2001-06-21 1:53 UTC (permalink / raw)
To: Ted Gervais; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.21.0106200804160.2944-100000@ve1drg.com>
I had a similar problem with this yesterday. Try moving your .config
file to a safe place, making mrproper, then moving your .config back and
rebuilding. I did this and all was well.
HTH,
pete
On Wed, 20 Jun 2001, Ted Gervais wrote:
> Wondering something..
> I ran insmod to bring up ip_tables.o and I received the following error:
>
> /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved
> symbol nf_unregister_sockopt
> /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved
> symbol nf_register_sockopt
>
> This is with kernel 2.4.5 and Slackware 7.1 is the distribution.
> Does anyone know what these unresolved symbols are about??
^ permalink raw reply
* Re: is there a linux running on jvm arch ?
From: H. Peter Anvin @ 2001-06-21 1:52 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <E15CqCJ-0000Co-00@the-village.bc.nu>
Followup to: <E15CqCJ-0000Co-00@the-village.bc.nu>
By author: Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> The JVM is very very bad from a C language point of view. You can convert C
> code to it and there have been some very experimental demos of this. However
> it is a very non trivial problem
>
Note that PicoJava is basically the JVM with a few extensions to run C
code reasonably. It might be a better target.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
^ permalink raw reply
* Re: freeze with 2.4.5-ac16
From: Justin Guyett @ 2001-06-21 1:53 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.21.0106202058050.13709-100000@freak.distro.conectiva>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 570 bytes --]
On Wed, 20 Jun 2001, Marcelo Tosatti wrote:
> > happened again (vt1 and 2 echo but shells are unresponsive, vt3+ don't
> > echo) only active process was the program allocating 192mb and writing to
> > it, no find this time.
>
> Can you get the backtrace of this process?
the offending process is memeat (allocates 192*1024*1024 bytes, then
memsets it to 0, then sleeps forever, though apparently it never gets to
that part). It has to be in memset(ptr, 0, 192*1024*1024).
ksymoops from sysrq-m attached, and vmstat from just before the hang and
just after.
justin
[-- Attachment #2: Type: TEXT/PLAIN, Size: 14975 bytes --]
free sibling
task PC stack pid father child younger older
init R current 0 1 0 1312 (NOTLB)
Call Trace: [<c01279a1>] [<c0127b06>] [<c012863a>] [<c01286dc>] [<c012588b>]
[<c0125a1f>] [<c0136ca9>] [<c0137bbd>] [<c0134d4e>] [<c0106aeb>]
keventd S FFFFFFFF 0 2 1 3 (L-TLB)
Call Trace: [<c011d2eb>] [<c010545c>]
kswapd R C1451FA8 0 3 1 4 2 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c011122a>] [<c0127aa1>] [<c010545c>]
kreclaimd S 00000286 0 4 1 5 3 (L-TLB)
Call Trace: [<c01111d5>] [<c0127b52>] [<c010545c>]
bdflush S 00000282 0 5 1 6 4 (L-TLB)
Call Trace: [<c01111d5>] [<c0131144>] [<c010545c>]
kupdated S C1479FC8 0 6 1 8 5 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c01311b9>] [<c010545c>]
kreiserfsd S CFAB9FB4 0 8 1 12 6 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c011122a>] [<c016b6f7>] [<c010545c>]
devfsd S CF706000 8 12 1 22 8 (NOTLB)
Call Trace: [<c015126c>] [<c015d890>] [<c015e145>] [<c0164cf7>] [<c016551f>]
[<c0194725>] [<c0165a22>] [<c0190948>] [<c01909a2>] [<c0157395>] [<c015758d>]
[<c0164b20>] [<c0157a79>] [<c0164cf7>] [<c016551f>] [<c013457c>] [<c012e040>]
[<c0158b16>] [<c0158f12>] [<c0164cf7>] [<c016551f>] [<d081a044>] [<c016c87a>]
[<c016cc09>] [<c016c256>] [<c0159073>] [<c0136e95>] [<c0134e14>] [<c012d7b6>]
[<c0106aeb>]
klogd S 7FFFFFFF 0 22 1 27 12 (NOTLB)
Call Trace: [<c0110c5f>] [<c01da0af>] [<c01da967>] [<c01a8345>] [<c01a856e>]
[<c012d87b>] [<c0106aeb>]
syslogd R 00000000 0 27 1 30 22 (NOTLB)
Call Trace: [<c012858c>] [<c01286dc>] [<c013ae57>] [<c01acdf0>] [<c01a874f>]
[<c013b036>] [<c013b490>] [<c0106aeb>]
kapm-idled S CF23FF94 0 30 1 53 27 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<d090a9d7>] [<d090bcdc>] [<d090c08c>]
[<d090c08c>] [<d090b2e5>] [<c0105453>] [<c010545c>]
cardmgr S 7FFFFFFF 4812 53 1 72 30 (NOTLB)
Call Trace: [<c0110c5f>] [<c019ff9c>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
sshd S 7FFFFFFF 0 72 1 74 53 (NOTLB)
Call Trace: [<c0110c5f>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
xfs S CE65FF2C 0 74 1 78 72 (NOTLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
zsh S CF94FFB0 0 78 1 1338 79 74 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
agetty S 7FFFFFFF 1172 79 1 81 78 (NOTLB)
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
zsh S 7FFFFFFF 0 81 1 122 79 (NOTLB)
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
zsh S CF1BDFB0 0 122 1 138 148 81 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
zsh S C30FFFB0 4708 138 122 150 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
gpm S C32D3F2C 4640 148 1 151 122 (NOTLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
[<c010002b>]
ssh S 7FFFFFFF 0 150 138 (NOTLB)
Call Trace: [<c0110c5f>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
agetty S 7FFFFFFF 0 151 1 1312 148 (NOTLB)
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
zsh S C9BCDFB0 24 1312 1 1431 151 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
zsh S C1AB2000 0 1319 78 1432 1338 (NOTLB)
Call Trace: [<c013614c>] [<c0136223>] [<c012d7b6>] [<c0106aeb>]
tail S CE86FF8C 24 1338 78 1319 (NOTLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c0119a48>] [<c0106aeb>]
memeat R 00000000 376 1431 1312 (NOTLB)
Call Trace: [<c012858c>] [<c011f0be>] [<c011f14b>] [<c011f25b>] [<c0110374>]
[<c01104d4>] [<c0110374>] [<c01aae1b>] [<c01194f9>] [<c01193d7>] [<c01195c4>]
[<c010a9f8>] [<c0110f3c>] [<c0110374>] [<c0106c18>]
zsh R 00000000 4600 1432 1319 (NOTLB)
Call Trace: [<c012858c>] [<c011eba2>] [<c011f291>] [<c0110374>] [<c01104d4>]
[<c0110374>] [<c0128c75>] [<c012d47c>] [<c0106c18>]
ksymoops 2.4.1 on i686 2.4.5-ac16. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.5-ac16/ (default)
-m /boot/System.map (specified)
Call Trace: [<c01279a1>] [<c0127b06>] [<c012863a>] [<c01286dc>] [<c012588b>]
[<c0125a1f>] [<c0136ca9>] [<c0137bbd>] [<c0134d4e>] [<c0106aeb>]
Call Trace: [<c011d2eb>] [<c010545c>]
Call Trace: [<c0110cbb>] [<c0110c00>] [<c011122a>] [<c0127aa1>] [<c010545c>]
Call Trace: [<c01111d5>] [<c0127b52>] [<c010545c>]
Call Trace: [<c01111d5>] [<c0131144>] [<c010545c>]
Call Trace: [<c0110cbb>] [<c0110c00>] [<c01311b9>] [<c010545c>]
Call Trace: [<c0110cbb>] [<c0110c00>] [<c011122a>] [<c016b6f7>] [<c010545c>]
Call Trace: [<c015126c>] [<c015d890>] [<c015e145>] [<c0164cf7>] [<c016551f>]
[<c0194725>] [<c0165a22>] [<c0190948>] [<c01909a2>] [<c0157395>] [<c015758d>]
[<c0164b20>] [<c0157a79>] [<c0164cf7>] [<c016551f>] [<c013457c>] [<c012e040>]
[<c0158b16>] [<c0158f12>] [<c0164cf7>] [<c016551f>] [<d081a044>] [<c016c87a>]
[<c016cc09>] [<c016c256>] [<c0159073>] [<c0136e95>] [<c0134e14>] [<c012d7b6>]
[<c0106aeb>]
Call Trace: [<c0110c5f>] [<c01da0af>] [<c01da967>] [<c01a8345>] [<c01a856e>]
[<c012d87b>] [<c0106aeb>]
Call Trace: [<c012858c>] [<c01286dc>] [<c013ae57>] [<c01acdf0>] [<c01a874f>]
[<c013b036>] [<c013b490>] [<c0106aeb>]
Call Trace: [<c0110cbb>] [<c0110c00>] [<d090a9d7>] [<d090bcdc>] [<d090c08c>]
[<d090c08c>] [<d090b2e5>] [<c0105453>] [<c010545c>]
Call Trace: [<c0110c5f>] [<c019ff9c>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
Call Trace: [<c0110c5f>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
Call Trace: [<c0110cbb>] [<c0110c00>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
Call Trace: [<c0110cbb>] [<c0110c00>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
[<c010002b>]
Call Trace: [<c0110c5f>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
Call Trace: [<c013614c>] [<c0136223>] [<c012d7b6>] [<c0106aeb>]
Call Trace: [<c0110cbb>] [<c0110c00>] [<c0119a48>] [<c0106aeb>]
Call Trace: [<c012858c>] [<c011f0be>] [<c011f14b>] [<c011f25b>] [<c0110374>]
[<c01104d4>] [<c0110374>] [<c01aae1b>] [<c01194f9>] [<c01193d7>] [<c01195c4>]
[<c010a9f8>] [<c0110f3c>] [<c0110374>] [<c0106c18>]
Call Trace: [<c012858c>] [<c011eba2>] [<c011f291>] [<c0110374>] [<c01104d4>]
[<c0110374>] [<c0128c75>] [<c012d47c>] [<c0106c18>]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c01279a1 <do_try_to_free_pages+19/58>
Trace; c0127b06 <try_to_free_pages+22/2c>
Trace; c012863a <__alloc_pages+1b2/240>
Trace; c01286dc <__get_free_pages+14/20>
Trace; c012588b <kmem_cache_grow+af/1fc>
Trace; c0125a1f <kmem_cache_alloc+47/54>
Trace; c0136ca9 <getname+19/98>
Trace; c0137bbd <__user_walk+11/58>
Trace; c0134d4e <sys_stat64+16/78>
Trace; c0106aeb <system_call+33/38>
Trace; c011d2eb <context_thread+ef/194>
Trace; c010545c <kernel_thread+28/38>
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c011122a <interruptible_sleep_on_timeout+42/5c>
Trace; c0127aa1 <kswapd+c1/e0>
Trace; c010545c <kernel_thread+28/38>
Trace; c01111d5 <interruptible_sleep_on+3d/50>
Trace; c0127b52 <kreclaimd+42/a0>
Trace; c010545c <kernel_thread+28/38>
Trace; c01111d5 <interruptible_sleep_on+3d/50>
Trace; c0131144 <bdflush+ac/b0>
Trace; c010545c <kernel_thread+28/38>
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c01311b9 <kupdate+71/e8>
Trace; c010545c <kernel_thread+28/38>
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c011122a <interruptible_sleep_on_timeout+42/5c>
Trace; c016b6f7 <reiserfs_journal_commit_thread+8f/d4>
Trace; c010545c <kernel_thread+28/38>
Trace; c015126c <devfsd_read+f4/3a8>
Trace; c015d890 <reiserfs_kfree+14/38>
Trace; c015e145 <unfix_nodes+155/160>
Trace; c0164cf7 <is_tree_node+37/54>
Trace; c016551f <search_by_key+80b/c64>
Trace; c0194725 <ide_dmaproc+13d/210>
Trace; c0165a22 <search_for_position_by_key+aa/380>
Trace; c0190948 <start_request+148/210>
Trace; c01909a2 <start_request+1a2/210>
Trace; c0157395 <make_cpu_key+39/40>
Trace; c015758d <_get_block_create_0+9d/5bc>
Trace; c0164b20 <pathrelse+1c/2c>
Trace; c0157a79 <_get_block_create_0+589/5bc>
Trace; c0164cf7 <is_tree_node+37/54>
Trace; c016551f <search_by_key+80b/c64>
Trace; c013457c <cdget+40/bc>
Trace; c012e040 <init_special_inode+44/d4>
Trace; c0158b16 <init_inode+1f2/1fc>
Trace; c0158f12 <reiserfs_read_inode2+be/c8>
Trace; c0164cf7 <is_tree_node+37/54>
Trace; c016551f <search_by_key+80b/c64>
Trace; d081a044 <_end+10569398/106593b4>
Trace; c016c87a <check_journal_end+20e/23c>
Trace; c016cc09 <do_journal_end+ad/a60>
Trace; c016c256 <journal_end+16/1c>
Trace; c0159073 <reiserfs_dirty_inode+4b/54>
Trace; c0136e95 <path_release+d/2c>
Trace; c0134e14 <sys_lstat64+64/70>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c01da0af <unix_wait_for_peer+9b/c0>
Trace; c01da967 <unix_dgram_sendmsg+2c3/370>
Trace; c01a8345 <sock_sendmsg+69/88>
Trace; c01a856e <sock_write+b2/bc>
Trace; c012d87b <sys_write+8f/c4>
Trace; c0106aeb <system_call+33/38>
Trace; c012858c <__alloc_pages+104/240>
Trace; c01286dc <__get_free_pages+14/20>
Trace; c013ae57 <__pollwait+33/8c>
Trace; c01acdf0 <datagram_poll+24/e4>
Trace; c01a874f <sock_poll+23/28>
Trace; c013b036 <do_select+e2/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; d090a9d7 <[apm]apm_mainloop+e3/100>
Trace; d090bcdc <[apm]error_table+4f8/85b>
Trace; d090c08c <[apm]apm_waitqueue+4/c>
Trace; d090c08c <[apm]apm_waitqueue+4/c>
Trace; d090b2e5 <[apm]apm+295/2a8>
Trace; c0105453 <kernel_thread+1f/38>
Trace; c010545c <kernel_thread+28/38>
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c019ff9c <ds_poll+64/78>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c017754d <read_chan+3a9/6f0>
Trace; c0173738 <tty_read+b0/d0>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c017754d <read_chan+3a9/6f0>
Trace; c0173738 <tty_read+b0/d0>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Trace; c010002b <startup_32+2b/a5>
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c017754d <read_chan+3a9/6f0>
Trace; c0173738 <tty_read+b0/d0>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Trace; c013614c <pipe_wait+7c/a4>
Trace; c0136223 <pipe_read+af/1f8>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c0119a48 <sys_nanosleep+108/180>
Trace; c0106aeb <system_call+33/38>
Trace; c012858c <__alloc_pages+104/240>
Trace; c011f0be <do_anonymous_page+32/90>
Trace; c011f14b <do_no_page+2f/e0>
Trace; c011f25b <handle_mm_fault+5f/cc>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c01104d4 <do_page_fault+160/45c>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c01aae1b <kfree_skbmem+b/54>
Trace; c01194f9 <update_process_times+1d/90>
Trace; c01193d7 <update_wall_time+b/3c>
Trace; c01195c4 <timer_bh+24/25c>
Trace; c010a9f8 <timer_interrupt+dc/158>
Trace; c0110f3c <schedule+250/370>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c0106c18 <error_code+38/40>
Trace; c012858c <__alloc_pages+104/240>
Trace; c011eba2 <do_wp_page+166/244>
Trace; c011f291 <handle_mm_fault+95/cc>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c01104d4 <do_page_fault+160/45c>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c0128c75 <free_page_and_swap_cache+b5/b8>
Trace; c012d47c <filp_close+5c/64>
Trace; c0106c18 <error_code+38/40>
1 warning issued. Results may not be reliable.
5:03pm up 1:51, 4 users, load average: 0.66, 0.61, 0.25
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 160528 79324 5708 165852 1 96 6 98 107 246 0 62 38
5:04pm up 1:52, 4 users, load average: 2.99, 1.26, 0.49
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
3 0 0 160528 79664 5756 165852 1 95 6 97 107 250 0 62 37
^ permalink raw reply
* RE: Why use threads ( was: Alan Cox quote?)
From: David Schwartz @ 2001-06-21 1:43 UTC (permalink / raw)
To: Mike Castle, linux-kernel
In-Reply-To: <20010620154319.A15561@thune.mrc-home.com>
> On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote:
> > As I said, you don't want to use one thread for each
> > client. You use, say,
> > 10 threads for the 16,000 clients. That way, if an occasional client
> > ambushes a thread (say by reading a file off an NFS server or
> > by using some
> > infrequently used code that was swapped to a busy disk), your
> > server will
> > keep on humming.
> This same approach can easily be used by multiple processes.
Theoretically, pretty much everything you can do with a thread pool
architecture can be done with a process pool architecture. Sharing file
descriptors can be much harder. Some thread architectures (notably pthreads)
go out of their way to make some things hard for thread pools (like try
implementing Samba, since all the threads share there uids). But this is
more about bad threading specifications and implementations than threading
itself.
> I don't see what is gained by using threads over processes for such an
> architecture.
I'll flip this back at you and ask you what's gained by using processes
over threads. It's certainly more difficult to implement a process pool
architecture than a thread pool architecture. Theoretically, performance for
a thread pool architecture will be slightly better (on some architectures at
least) due to the identical vm views.
With a process pool architecture, you might have more control over what you
share. But this doesn't actually gain you anything because as long as you
share more than a small amount, you still have to consider your entire
environment tainted if one execution vehicle goes out of control.
I would be very interested in seeing, for example, a web server based on a
'process pool' design. Does anybody know of any?
DS
^ permalink raw reply
* Re: freeze with 2.4.5-ac16
From: Marcelo Tosatti @ 2001-06-20 23:58 UTC (permalink / raw)
To: Justin Guyett; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0106201527120.29004-100000@gw.soze.net>
On Wed, 20 Jun 2001, Justin Guyett wrote:
> On Wed, 20 Jun 2001, Justin Guyett wrote:
>
> > I got it to freeze in console (two generic find / -type f / type d), one
> > process allocating and writing 0 to 192mb
> >
> > machine responds to pings, switching VTs works
> >
> > (256 physical, 512 swap)
>
> happened again (vt1 and 2 echo but shells are unresponsive, vt3+ don't
> echo) only active process was the program allocating 192mb and writing to
> it, no find this time.
Can you get the backtrace of this process?
^ 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.