Linux-Development-Sys Digest #145, Volume #8 Wed, 13 Sep 00 19:13:11 EDT
Contents:
Re: printk() ("Chris")
Parsing /proc/net/route (Tony Willoughby)
Parsing /proc/net/route (Tony Willoughby)
Re: scheduling under Linux not suitable for interactive work? (Paul Hughett)
Re: scheduling under Linux not suitable for interactive work? (Philip Armstrong)
aic7xxx 2.4.0 kernel module...gone ("Darren Welson")
Re: scheduling under Linux not suitable for interactive work? (Szabolcs Csetey)
Re: aic7xxx 2.4.0 kernel module...gone (Josef Oswald)
Re: Zip 100 Parallel Port Drive (James Franklin)
Re: scheduling under Linux not suitable for interactive work?
([EMAIL PROTECTED])
Re: scheduling under Linux not suitable for interactive work? (Kaz Kylheku)
IA-64 Linux Developers Kit updates now available... ([EMAIL PROTECTED])
Re: scheduling under Linux not suitable for interactive work? (Brett Johnson)
Re: new windowing system (Karl Heyes)
----------------------------------------------------------------------------
From: "Chris" <[EMAIL PROTECTED]>
Subject: Re: printk()
Date: Wed, 13 Sep 2000 12:12:31 -0700
Did you try running xconsole?
------------------------------
From: Tony Willoughby <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.development.system
Subject: Parsing /proc/net/route
Date: Wed, 13 Sep 2000 15:17:14 -0400
Are there any known issues with /proc/net/route? It seems that
reading /proc/net/route doesn't alway return all of the routes in the
routing table.
I'm writing a user-space program (that runs as root) that will go
through the routing table and delete routes with a specific gateway.
It opens /proc/net/route and reads each line by calling fgets() in a
loop until fgets() returns NULL.
Almost always, when there are several (more than 30 or so), routes in
the table fgets() returns NULL before all of the routes have been
read. Subsequent executions of this program will delete some (or all)
of the remaining routes. If the program is run enough times all of
the desired routes will be deleted.
The algorithm for reading/parsing the contents of /proc/net/route is
loosely based on netstat.c from net-tools-1.53.
I'm running 2.2.14-12. A Red Hat distribution.
Is anyone aware of any problems with /proc/net/route?
Thanks.
--
|
Tony Willoughby | Some nights I can't tell which finger the
[EMAIL PROTECTED] | thumb pick goes on.
| -Warren Zevon
------------------------------
From: Tony Willoughby <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.development.system
Subject: Parsing /proc/net/route
Date: Wed, 13 Sep 2000 15:17:14 -0400
Are there any known issues with /proc/net/route? It seems that
reading /proc/net/route doesn't alway return all of the routes in the
routing table.
I'm writing a user-space program (that runs as root) that will go
through the routing table and delete routes with a specific gateway.
It opens /proc/net/route and reads each line by calling fgets() in a
loop until fgets() returns NULL.
Almost always, when there are several (more than 30 or so), routes in
the table fgets() returns NULL before all of the routes have been
read. Subsequent executions of this program will delete some (or all)
of the remaining routes. If the program is run enough times all of
the desired routes will be deleted.
The algorithm for reading/parsing the contents of /proc/net/route is
loosely based on netstat.c from net-tools-1.53.
I'm running 2.2.14-12. A Red Hat distribution.
Is anyone aware of any problems with /proc/net/route?
Thanks.
--
|
Tony Willoughby | Some nights I can't tell which finger the
[EMAIL PROTECTED] | thumb pick goes on.
| -Warren Zevon
------------------------------
From: Paul Hughett <[EMAIL PROTECTED]>
Subject: Re: scheduling under Linux not suitable for interactive work?
Date: 13 Sep 2000 19:29:42 GMT
Szabolcs Csetey <[EMAIL PROTECTED]> wrote:
Something seems very broken ... A typical
: vmstat output,
: procs memory swap io system cpu
2 0 2 58828 1204 15772 46568 0 0 483 501 637 1649 4 6 90
: 2 0 0 58828 2192 15296 46000 0 0 175 0 665 1473 6 6 88
: 0 1 1 58828 3132 15764 44668 0 0 1821 1843 684 1726 3 15 83
: 1 11 1 70996 56144 3300 16512 1704 12464 3298 5555 5287 3710 0 10 89
: 1 14 0 70920 54200 3816 17868 432 0 361 0 307 143 0 2 98
: 1 12 0 70820 52568 4268 18940 248 0 294 0 259 157 0 2 98
: 0 14 0 70760 50652 4732 20332 268 0 368 441 317 346 0 2 98
: 0 13 0 70696 48936 5140 21580 344 0 333 0 259 299 0 3 97
: 0 12 0 70660 47196 5588 22824 252 0 322 0 357 323 1 4 95
: 1 10 0 70560 45316 6048 24152 380 0 359 0 274 346 1 2 97
^^^ ^^
Your problem is that you don't have enough real memory to support whatever
you're trying to do simultaneously. What you're seeing here is that one
process keeps grabbing more memory; then the other one resumes and grabs
memory, forcing the first one's memory out to swap; then the first process
slows down because it's got to retrieve its pages from swap, while forcing
the second processes back out to swap, from which it will have to retrieve
them later. The phenomenon is called "trashing" and can give you massive
hits in both throughput and latency. Generally speaking, the only cure is
to add more real memory or try to do less at the same time. If you look
at ps or top output, you can probably tell which are the memory hogs.
Paul Hughett
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: scheduling under Linux not suitable for interactive work?
Date: 13 Sep 2000 21:00:29 +0100
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Robert Redelmeier <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] wrote:
>...
>>
>> Those compute-intensive tasks wouldn't be memory intensive,
>> by any chance? Were you hitting swap? Thrashing? Swap might
>> get queued to the disk ahead of normal r/w and essentially
>> block-out the disk IO that emacs [...ugh] heavily depends on.
>>
>I don't have a swap partition. The console did not show any messages
^^^^^
You need one (or a swap file). Your problem is probably due to memory
pressure. In the abscence of a swap file to page out dirty data pages
to disk, linux will re-use application text pages (which contain the
executable code for the app) which it knows it can reload from disk as
required. If you give it a swap file, the kernel will be able to swap
out unused data pages + free up much needed memory.
64Mb usually swaped a bit on my home machine with X + emacs + netscape
running. Without a swap file, I imagine it would be unusable :)
With 128Mb, everything fits in core though, which is much nicer...
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: "Darren Welson" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.misc,comp.os.linux.setup
Subject: aic7xxx 2.4.0 kernel module...gone
Date: Wed, 13 Sep 2000 12:51:15 -0700
Every time I recompile 2.4.0-test 6,7, and 8 kernel, I cannot seem to
successfully load the AIC7XXX module, or at least have it made. Anyone know
how I can check to make sure I am actually making this module, or find a way
I can to compile it into the kernel? I have added it as a module and IN the
kernel in all three test versions as a low-level SCSI option, but what am I
missing?
darren
------------------------------
From: Szabolcs Csetey <[EMAIL PROTECTED]>
Subject: Re: scheduling under Linux not suitable for interactive work?
Date: Wed, 13 Sep 2000 20:26:53 GMT
Paul Hughett <[EMAIL PROTECTED]> wrote:
> Your problem is that you don't have enough real memory to support
> whatever you're trying to do simultaneously.
Thanks Paul. Sure, with 1 GB RAM probably I wouldn't have this annoyance
but I also didn't have this in the last 5 years doing about the same on
much less powerful boxes. I KNOW what causes the problem - doing disk IO
with bigger files (5-100 MB). The program itself even doesn't use
usually more than a few ten Kbytes. It seems the kernel prefer to cache
HUGE amount of useless disk data instead of trying to keep in memory the
useful "running" application data/code :( I'm a bit afraid this is one
of the results of the "let's do better benchmark result" at the expense
of usability.
> What you're seeing here
> is that one process keeps grabbing more memory; then the other one
> resumes and grabs memory, forcing the first one's memory out to swap;
> then the first process slows down because it's got to retrieve its
> pages from swap, while forcing the second processes back out to swap,
> from which it will have to retrieve them later. The phenomenon is
> called "trashing" and can give you massive hits in both throughput and
> latency. Generally speaking, the only cure is to add more real memory
> or try to do less at the same time. If you look at ps or top output,
> you can probably tell which are the memory hogs.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Josef Oswald <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: aic7xxx 2.4.0 kernel module...gone
Date: Wed, 13 Sep 2000 20:40:27 GMT
Remember Darren those Kernels are _unstable_ Versions :-(
I tried to kompile one 2.4.test8 now three times and for some reason
when I want to access my fvat partitions I get the message vfat not
supported by kernel...... ( and yes I even compiled it fix in the kernel
and not as a module)
I know that is not a answer to your question though..:-( Sorry
Darren Welson wrote:
>
> Every time I recompile 2.4.0-test 6,7, and 8 kernel, I cannot seem to
> successfully load the AIC7XXX module, or at least have it made. Anyone know
> how I can check to make sure I am actually making this module, or find a way
> I can to compile it into the kernel? I have added it as a module and IN the
> kernel in all three test versions as a low-level SCSI option, but what am I
> missing?
>
> darren
--
Josef Oswald [EMAIL PROTECTED]
registered-linux-user # 13.818 at http://counter.li.org
------------------------------
From: [EMAIL PROTECTED] (James Franklin)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: Zip 100 Parallel Port Drive
Reply-To: [EMAIL PROTECTED]
Date: 13 Sep 2000 16:26:38 -0600
On Wed, 13 Sep 2000 10:44:22 +0200, Kasper Dupont wrote:
>Wouter Verhelst wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> Kasper Dupont <[EMAIL PROTECTED]> writes:
>> > The speed for reading is as far as i remember:
>> >
>> > SPP: less than 200 kb/sec
>> > ECP under DOS: 300 kb/sec
>> > EPP under DOS: 400 kb/sec
>> > EPP under Linux: 500 kb/sec
>> >
>> > For some reasons many new computers come with the BIOS default
>> > set to SPP, does anyone have a very good explanation for that?
>>
>> I'm not sure about this, but perhaps because SPP is the oldest (is
>> it?) so the 'default' that is supported by all OSses, also broken
>> ones?
>> Wouldn't make sense, but ya never know ;-)
>
>Could make sense, but all software I have seen using
>SPP works fine even with the bios set to EPP. And I
>also think it would be a very strange choice to
>configure new computers for old broken software
>instead of configuring them for the new and more
>effective ones.
>
>--
>Kasper Dupont
I have my Compaq Presario 4660 set to ECP in the BIOS and run a Zip100 and
Epson Stylus Color 740 on the parallel port. It all works.
--
James
A Daily Quip, Quote, or Fortune:
The primary cause of failure in electrical appliances is an expired
warranty. Often, you can get an appliance running again simply by changing
the warranty expiration date with a 15/64-inch felt-tipped marker.
-- Dave Barry, "The Taming of the Screw"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: scheduling under Linux not suitable for interactive work?
Date: 14 Sep 2000 08:53:55 +0000
[EMAIL PROTECTED] (Philip Armstrong) writes:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >Robert Redelmeier <[EMAIL PROTECTED]> writes:
> >
> >> [EMAIL PROTECTED] wrote:
> >...
> >>
> >> Those compute-intensive tasks wouldn't be memory intensive,
> >> by any chance? Were you hitting swap? Thrashing? Swap might
> >> get queued to the disk ahead of normal r/w and essentially
> >> block-out the disk IO that emacs [...ugh] heavily depends on.
> >>
> >I don't have a swap partition. The console did not show any messages
> ^^^^^
> You need one (or a swap file). Your problem is probably due to memory
> pressure. In the abscence of a swap file to page out dirty data pages
^^^^^^^^
Thanks Phil.
I'll make some additional experiments to check various theories people
presented in their replies. I can notice that everything revolves
about insufficient memory. The same PC worked happily with 32Mb and
48Mb under similar circumstances. I find it REALLY HARD to believe
that one X server, one emacs session (editting 2MB text file) and a
couple of X terms cannot fit 64MB comfortably. I would find it hard to
believe even if memory was only 32MB. X server and emacs are not so
huge applications, nor the file size is testing the system
limits. That's why I suspected that running of emacs replace command
has taken up all the CPU time (I'll try to check this when I get home)
and that the Linux scheduler failed to lower emacs' running priority
to allow me to easily switch to other windows/applications. Even if
the whole file was buffered, say, 10 times, it would still be only
20MB and I don't see how the memory could be a problem. On the other
hand, if disk LED is any indication of disk activity, there was some
intermittent activity, but I've seen programs that make the LED bright
red, and the system could still react to mouse events etc.
Interestingly enough, when I rebooted Windows95 on the SAME machine
(don't flame me for this :-), I ran Windows version of emacs (19.x vs
20.x on Linux), and tried the same thing with the same file and, while
the load on the system was apparent, the system maintained reasonable
interactive responsiveness, certainly much better than I had on
Linux/X windows.
I'll make some experiments as soon as I have some more time to clarify
the situation and provide more data.
Regards,
Milan
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: scheduling under Linux not suitable for interactive work?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 22:18:32 GMT
On 14 Sep 2000 08:53:55 +0000, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>Interestingly enough, when I rebooted Windows95 on the SAME machine
>(don't flame me for this :-), I ran Windows version of emacs (19.x vs
>20.x on Linux), and tried the same thing with the same file and, while
>the load on the system was apparent, the system maintained reasonable
>interactive responsiveness, certainly much better than I had on
>Linux/X windows.
I think you have a bad kernel binary, or some other system file. Try
reinstalling, preferrably from a different CD ROM.
If you can't reproduce the problem using a different installation of the same
or similar configuration, then it's not a real problem with the software. Shit
happens sometimes: out of the millions of people using Linux, once in a while
someone gets a flipped bit and encounters strange behavior. The problem could
be bad installation media, bad hardware or some random act of nature. (Let's
face it, PC's are not exactly hardware that could be trusted as the basis for a
safety-critical application).
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED]
Subject: IA-64 Linux Developers Kit updates now available...
Date: Wed, 13 Sep 2000 22:17:31 GMT
This will probably be of interest to those of you immersed in IA-64
Linux ports...
It was posted on HP's Developer's Resource Forums
(http://www.devresource.hp.com/devresource/Forums/Forums.html).
>Posted by Brian Lynn ([EMAIL PROTECTED]) on 09/08/00 17:12
>Updates to the IA-64 Linux Developers Kit are now available at the HP
>web site.
>Changes have been made to Ski (more system calls are supported, big-
>endian mode works correctly, etc.) and the NUE filesystem (updated
>toolchain, etc.).
>A list of changes, along with links that will take you to the new
>files, can be found at
>http://www.software.hp.com/products/LIA64/updates.htm. The LDK URL
>continues to be http://www.software.hp.com/ia64linux/.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Brett Johnson <[EMAIL PROTECTED]>
Subject: Re: scheduling under Linux not suitable for interactive work?
Date: Wed, 13 Sep 2000 16:46:57 -0600
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> I find it REALLY HARD to believe
> that one X server, one emacs session (editting 2MB text file) and a
> couple of X terms cannot fit 64MB comfortably.
Just for grins, look at "top"
when you're in this situation to see the resident
process size of X & emacs. Mine reports:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
735 root 8 0 66060 61M 1336 S 0 4.5 16.2 181:27 X
7684 brett 4 0 7096 7096 2896 S 0 10.1 1.8 0:01 emacs
which adds up to about 71Meg, just for X & emacs. That doesn't even count
all of the daemons that are running, memory the kernel locks down for
itself, the window manager you're running on top of X, etc...
Cheers!
--
Brett
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: new windowing system
Date: Thu, 14 Sep 2000 00:06:05 +0000
In article <8pohd0$8c3$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>
> It seems to me that many people are dissatisfied with X Windows. I myself am
> one of them. It takes up a lot of memory. It is not too difficult to code for
> but is bulky and people say it has security holes. Has anyone developed an
> alternative, however? It seems to me that the fact that X uses sockets is
> bound to reduce performance and increase memory use, as well. I myself have
> only very rarely run a program on another computer and displayed the window
> on my system. Is there any reason why a simple windowing system cannot exist
> as a driver?
>
The X server has always known to be a fat beast, The X license has been an
issue just like the BSD one, see the X11R6.4 fiasco not so long ago. But the
key element to it has been standardisation. There are some real issues with
it for a long time that a very slowly being addressed eg fonts and
transparencies for instance.
The only alternative at the moment seems to be berlin
www.berlin-consortium.org but beware of its status.
karl
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
