Linux-Development-Sys Digest #689, Volume #8 Fri, 4 May 01 04:13:14 EDT
Contents:
Re: IO system throughput (Greg Copeland)
Re: Is linux kernel preemptive?? (Greg Copeland)
Re: IO system throughput ([EMAIL PROTECTED])
programming the serial port (Javier Loureiro Varela)
Re: Cannot get PHP 4 to compile for my system ("Bjorn Pearson")
Re: About jiffies in Kernel (=?iso-8859-1?Q?Andr=E9?= David)
Re: Interprocess Communication...help.... (Eric P. McCoy)
Re: Cannot load shared object file (Martin)
Re: how to register a pci device?
Re: About jiffies in Kernel
Re: Transfer data to mySQL Server (Frank Ranner)
Test ("Mulder H.")
STLport 4.0 & g++ 2.96 (Steve Connet)
Hot plug PCI device ("Mulder")
Re: Is linux kernel preemptive?? (Rik van Riel)
Re: Startup service ("D. Stimits")
Re: Hot plug PCI device ("D. Stimits")
Re: STLport 4.0 & g++ 2.96 ("D. Stimits")
Re: malloc Bug? (Torsten Blank)
----------------------------------------------------------------------------
Subject: Re: IO system throughput
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 03 May 2001 11:17:28 -0500
It's important to remember that the implementation requires kernel support.
This is the only way it can dispatch on the number and type of events that
it can. Think of this as being a hybrid approach much in the same way that
threads often require both kernel and user space support.
Greg
[EMAIL PROTECTED] writes:
> Greg Copeland <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] writes:
>
> > [snip]
> >> What do you think of the following system call that exists under FreeBSD
> >> and allows to do the thing you like, if i don't err:
> >>
> >> int
> >> kqueue(void)
> >>
>
> > Ya, I read an article about this a number of months back. I think it's pretty
> > cool. From that I've *read*, it is doing exactly what I've been talking about.
> > My memory is a little fuzzy on this, but I think a similar project is underway
> > for Linux. I don't remember if it was being built on the kqueue system or not.
> > Sorry. As for how well the above implementation works, I honestly don't know,
> > but from what I've read, they've done an excellent job.
>
> From what i have read also in FreeBSD mailing lists, this mechanisms
> allows very good performance in some cases. Note that forking a new
> process is extremely fast on Linux, more than in FreeBSD, so that
> this mechanism is perhaps not as useful as in FreeBSD.
>
> > --
> > Greg Copeland, Principal Consultant
> > Copeland Computer Consulting
> > --------------------------------------------------
> > PGP/GPG Key at http://www.keyserver.net
> > DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
> > --------------------------------------------------
>
> --
> Michel Talon
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: Is linux kernel preemptive??
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 03 May 2001 11:35:53 -0500
Thanks. That's been my point. Please clarify
why you think that interrupt handlers do not
count as system calls. Let's review this. Both
reside within the kernel. Both are functions. Both
are called to service a specific level of functionality.
The only distinction is that one is invoked directly by
an asynchronous interrupt handler while the other is a
synchronous call. Hardly worth making the distinction
unless you are getting into a microscopic conversation,
which I have pointed out that I was specifically trying
to avoid. Now then, since I feel sure that we can agree
on the above, adding this level of detail to a high level
conversation, I would submit, offers no additional value.
Keep in mind, interrupt handlers can and do call other
system calls. In essence, when you say an "interrupt
handler", you are really describing an asynchronous entry
point to a system call. In the original conversation, the
fact that something was being called asynchronously was
specifically deemed, by me, as irrelevant because the level
of detail at that point in time could not make any meaningful
distinction as to it exact behavior to make mention worthy.
The use of "system call" is a very ambiguous term which I
feel people often assign specific attributes that does not
really exist. I like to avoid all of that and think of
system calls as just that. A function residing within the
"system". In this case, I think of "system" as being "the
kernel." I find that for the vast majority of conversations,
the concept holds true and greatly simplifies the thread as
far fewer assumptions are needed by the participants.
Hope this helps.
Thanks,
Greg
[EMAIL PROTECTED] (Neal Tucker) writes:
> Greg Copeland <[EMAIL PROTECTED]> wrote:
> >Kasper Dupont <[EMAIL PROTECTED]> writes:
> >
> >> A system call cannot preempt another
> >> system call, no matter what the system looks like.
> >
> >And when an interrupt is processed, is it something
> >magical, or rather, an interrupt handler which is
> >pretty much a system call.
>
> I think if you guys start this conversation over after
> agreeing on some definitions ("system call" seems like an
> obvious one to work out, and conventionally does *not*
> include interrupt handlers, I would guess), you'll find
> that you agree on a lot more.
>
> -Neal Tucker
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IO system throughput
Date: Thu, 3 May 2001 16:38:01 +0000 (UTC)
Greg Copeland <[EMAIL PROTECTED]> wrote:
> It's important to remember that the implementation requires kernel support.
> This is the only way it can dispatch on the number and type of events that
> it can. Think of this as being a hybrid approach much in the same way that
> threads often require both kernel and user space support.
> Greg
I have recently read a quite complete discussion of the subject that you
may find interesting. It is
http://www.kegel.com/c10k.html
and speaks a lot about linux issues.
--
Michel Talon
------------------------------
From: [EMAIL PROTECTED] (Javier Loureiro Varela)
Subject: programming the serial port
Date: Thu, 03 May 2001 16:57:53 GMT
hello!
I'm coding some stuff with datagrams and my serial port
(related to some telephony devices). Everything works, but I'd like to
improve the feautures for the serial port, like timeout, carrier
detect, and maybe, autodetection of some parameters.
I believe that there are some sites or some mailing list
related for this issue... or even, a good reference book for all
this...
any suggestion?
thanks in advance
--
signed,
Javier Loureiro Varela
Class One
System Research Leader
------------------------------
From: "Bjorn Pearson" <[EMAIL PROTECTED]>
Subject: Re: Cannot get PHP 4 to compile for my system
Date: Thu, 3 May 2001 11:30:19 -0500
You might want to correct the date on your system, that might fix the
problem
"Mark D" <[EMAIL PROTECTED]> wrote in message
news:dRRB6.7487$[EMAIL PROTECTED]...
> I have been trying to compile PHP 4 into my system.
>
> The ./configure lines is as follows:
>
> rm config.cache
>
./configure --with-apxs --with-imap=/usr/lib --without-kerberos --without-my
> sql --with-pgsql=/usr/lib/pgsql
> make clean
> make
> make install
>
> Compilation goes well, but.......
>
> The error I get when I try to start apache is as follows :-
>
> Starting httpd: Syntax error on line 872 of /etc/httpd/conf/httpd.conf:
> Cannot load /etc/httpd/modules/libphp4.so into server:
> /etc/httpd/modules/libphp4.so: undefined symbol: gss_mech_krb5
>
> Any ideas? This is driving me batty.
>
> Regards
>
> Mark
>
>
>
------------------------------
From: =?iso-8859-1?Q?Andr=E9?= David <[EMAIL PROTECTED]>
Subject: Re: About jiffies in Kernel
Date: Thu, 03 May 2001 21:06:57 +0200
This is a multi-part message in MIME format.
==============9645F158B1D170D84C96D1CB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ouyang wrote:
>
> I am a newbie in linux kernel programming.
> I am trying to get time measurement in kernel.
> Am I right to use jiffies? I am not sure about it.
> If I am right, then what's the precision of jiffies?
>
> Thanks a lot.
>
> - ouyang
I have been using jiffies for benchmarking and it seems reasonable. A
jiffie is 10ms in x86 arch's, but it could be different for other
arch's, like Alpha, where HZ is different (1024 ticks per second vs the
x86 100 ticks per second).
The definition of jiffies is: the number of elapsed ticks since the
system was started. It is incremented by one everytime a timer interrupt
occurs.
Hope it helps,
andre
--
"Share the code. If you hide it ain't good."
Popular knowledge
==============9645F158B1D170D84C96D1CB
Content-Type: text/x-vcard; charset=us-ascii;
name="Andre.David.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Andr� David
Content-Disposition: attachment;
filename="Andre.David.vcf"
begin:vcard
n:David;Andr�
tel;work:+41792013849
x-mozilla-html:FALSE
org:CERN - Centre Europeen de Recherche Nucleaire;Experimental Physics Division - NA60
Experiment
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
note:Geneva, Switzerland
x-mozilla-cpt:;-11552
fn:Andr� David
end:vcard
==============9645F158B1D170D84C96D1CB==
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Interprocess Communication...help....
From: [EMAIL PROTECTED] (Eric P. McCoy)
Date: 03 May 2001 17:17:11 -0400
Followups set to c.o.l.d.apps.
Karim Atiki <[EMAIL PROTECTED]> writes:
> 1) I've an application, qt based,named APP1. this application gets some
> parameters from Gfx Widgets.
> Then , user pushes a run button in order to launch another application
> (APP2)
> I launch it by using fork() and execle()....
So far, so good.
> 2) So the next step is:
> to communicate between the 2 application.
> I want APP1 gives orders to APP2 such like "RUN", "PAUSE", "RESUME".
> For each of these commands, I want APP2 to notifiy APP1 that commands
> have been correctly handled.
Basically, you need to call pipe() before fork(), which ensures the
descriptors are present in both processes. Then, when the new process
is started, close the unused descriptors. APP2 will need to be made
aware of the descriptor to use for communication. You can use a
well-known descriptor, like stdin or stdout, or you can pass the
descriptor number on the command line of APP2.
For example, in APP1:
int fds[2], pid;
pipe(&fds);
if((pid = fork()) < 0) { /* error handling */ }
else if(!pid) {
char fd_string[11];
close(fds[0]);
sprintf(fd_string, "%ld", fds[1]);
execl("APP2", "APP2", fd_string, NULL);
perror("execl");
exit(1);
}
else {
close(fds[1]);
/* listen for inbound commands */
}
And in APP2:
int main(int argc, char **argv) {
int fd;
fd = strtoul(argv[1], NULL, 10);
/* do things and occasionally send a command to `fd' */
exit(0);
}
This is obviously untested code, but it should get you started.
--
Eric McCoy <[EMAIL PROTECTED]>
"Knowing that a lot of people across the world with Geocities sites
absolutely despise me is about the only thing that can add a positive
spin to this situation." - Something Awful, 1/11/2001
------------------------------
From: Martin <martin.o_brien@[no-spam]which.net>
Subject: Re: Cannot load shared object file
Reply-To: martin.o_brien@[no-spam]which.net
Date: Thu, 3 May 2001 22:17:05 +0100
Paul Kimoto wrote:
> libstdc++-libc6.1-2.so.3
> and
> libstdc++-libc6.2-2.so.3
> are different libraries with different sonames, and thus
> neither is
> supposed to be a replacement for the other. (Presumably the
> first is for programs built against glibc-2.1.*; and the
> second, against glibc-2.2.*.)
>
My distro has put on glibc-devel 2.2.2 and glibc 2.2.2. How do
I get apps. to access the libstdc++-3-libc6.1-2-2.10.0.so
library?
KPackage tells me that, for example, cdrdao needs
libstdc++-3-libc6.1-2-2.10.0.so, and it also tells me it's not
installed.
These distros really should get their act together.
Martin
http://homepages.which.net/~martin.o_brien/
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: how to register a pci device?
Date: Thu, 03 May 2001 22:59:39 -0000
In article <[EMAIL PROTECTED]>,
Ronnie Arosa Carril <[EMAIL PROTECTED]> wrote:
>How should I do to register a device driver? I' ve been looking some of
>the PCI device driver source codes. They never use the function
>register_chrdev()
I see several that do. One is stallion.c.
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: About jiffies in Kernel
Date: Thu, 03 May 2001 23:22:49 -0000
In article <[EMAIL PROTECTED]>,
Andr� David <[EMAIL PROTECTED]> wrote:
>I have been using jiffies for benchmarking and it seems reasonable. A
>jiffie is 10ms in x86 arch's, but it could be different for other
>arch's, like Alpha, where HZ is different (1024 ticks per second vs the
>x86 100 ticks per second).
It could be different in x86 too. You can change the value of HZ and
recompile.
--
http://www.spinics.net/linux
------------------------------
From: Frank Ranner <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Transfer data to mySQL Server
Date: Fri, 04 May 2001 12:06:21 +1000
[EMAIL PROTECTED] wrote:
>
> Hi,
> >
> >One really big question is "what format is your current data in"?
> It could be ASCII or any other format, because i develope also the program
> in win32 which will send the data to the linux red hat server.
>
> Bye
> Julia
Why don't you go to www.mysql.com where you will find all the
information you need.
Specifically, if you want your windows program to connect to the mysql
database you need
either a client library, or the myodbc package. From the website:
====================================
MySQL++ is a C++ API for MySQL (and other SQL Databases Soon). The goal
of this API is
to make working with queries as easy as working with other STL
Containers.
Current version is: 1.7.8
[snip]
MySQL++ 1.7.1 for Borland C++ 5.* for Windows (contributed by Arturs
Aboltins
<[EMAIL PROTECTED]>)
MySQL++ 1.7.1 for Microsoft Visual C++ 6.0 (contributed by LazyFox
<[EMAIL PROTECTED]>)
==========================================
MyODBC for Windows
MyODBC 2.50.37 for Windows95/98 (full setup)
MyODBC 2.50.37 for NT/2000 (full setup)
MyODBC 2.50.37 Windows95/98 and NT/2000 (only myodbc.dll and
myodbc2.dll)
Source for MyODBC 2.50.37 for Windows95/98 or NT/2000 Note that you need
the
3.23.xx client distribution to compile this! You can also use the
3.23.xx clients with
earlier mysqld servers.
==========================================
Regards, Frank Ranner
------------------------------
From: "Mulder H." <[EMAIL PROTECTED]>
Subject: Test
Date: Fri, 4 May 2001 11:05:40 +0800
Sorry, This is a test ~~
------------------------------
Subject: STLport 4.0 & g++ 2.96
From: Steve Connet <[EMAIL PROTECTED]>
Date: Fri, 04 May 2001 04:36:31 GMT
I'm using Linux kernel 2.2.16-22 & RH7.0. Not sure where else to ask
this question so if it's off topic, kindly direct me to the correct
forum.
I am trying to compile the STLport4.0 with g++ 2.96. I get to a file
called money_put_w.cpp and I get the following:
c++ -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-ftemplate-depth-32 -g -fPIC money_put_w.cpp -c -o obj/GCC/DebugD/money_put_w.o
c++: Internal error: Segmentation fault (program cpp0)
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make: *** [obj/GCC/DebugD/money_put_w.o] Error 1
[sconnet@rigel]/usr/devel/STLport-4.0/src>
I understand reverting back to g++ 2.95 is next to impossible since
everything on my system is compiled with 2.96??
Any ideas would be appreciated. The only other compiler I have is
egcs-2.91.66.
--
Steve Connet Remove USENET to reply via email
[EMAIL PROTECTED]
------------------------------
From: "Mulder" <[EMAIL PROTECTED]>
Subject: Hot plug PCI device
Date: Fri, 4 May 2001 13:07:20 +0800
Hi,
I am developing a PCI card and its Linux driver as well.
There is a PCI protection card between PCI bus and my PCI card.
The PCI protection card can turn my PCI card on/off when PC is ON.
When PC is booted into Linux with this PCI card on,
I can see this card's resource in /proc/pci and access it.
To save reboot time, if I found some H/W bugs, I'd like to turn off the
power
to this card, removed it from the PCI protection card, fix the H/W bugs,
re-plugget it to the PCI protection card, and turn off the power to this
card.
After this routine, I still can see this card's in /proc/pci.
However, this card can't be accessed correctly now.
All read returns 0xFFFFFFFF.
How can I debug the H/W of a PCI card without rebooting PC ?
Thanks!
------------------------------
From: Rik van Riel <[EMAIL PROTECTED]>
Subject: Re: Is linux kernel preemptive??
Date: Fri, 4 May 2001 03:26:46 -0300
Greg Copeland wrote:
> Thanks. That's been my point. Please clarify
> why you think that interrupt handlers do not
> count as system calls. Let's review this. Both
> reside within the kernel. Both are functions. Both
> are called to service a specific level of functionality.
> The only distinction is that one is invoked directly by
> an asynchronous interrupt handler while the other is a
> synchronous call.
Not true.
1. interrupts can interrupt normal kernel code, this means they
cannot take normal spinlocks, etc...
2. interrupts do not run in process context, while system calls
do
3. interrupts cannot context switch or schedule, while system
calls can
4. system calls and interrupts are called to service at a VERY
different level of functionality ... the system call code has
most of the kernel's "luxuries" available, while interrupts
have to run in a very bare-bones environment
--
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
------------------------------
Date: Fri, 04 May 2001 01:59:20 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Startup service
Kasper Dupont wrote:
>
> D. Stimits wrote:
> >
> > Xiaomu Zeng wrote:
> > >
> > > "D. Stimits" wrote:
> > >
> > > > >
> > > > > aha so it is rc.local i am looking for?
> > > >
> > > > If your only concern is to run some command at startup, yes. If it must
> > > > be controlled for start and stop activity at various runlevels, you'd
> > > > create a script to go in the init.d subdirectory; then links from the
> > > > various runlevel directories would determine whether the script is
> > > > called with a start or stop at the given runlevels. inetd is a sample of
> > > > something controlled at various runlevels, as well as a few other
> > > > daemons. To see a list of what is controlled to start or stop, try this:
> > > > chkconfig --list
> > > > (chkconfig might not be available under all distributions, I haven't
> > > > checked)
> > > >
> > >
> > > So rc.local will always be ran, at any init level (even single user mode)?
> > >
> > > Xiaomu
> >
> > I have not actually tested to give you an answer. It does not use the
> > normal runlevel scripting, so I believe it likely does (without looking
> > I am guessing that the rc main init script always calls rc.local once it
> > has finished the last runlevel it is aiming for, aside from shutdown).
> > The way to test it would be to add a line to rc.local such as:
> > echo "rc.local has run" > /tmp/rc.test.txt
> >
> > Make sure that file is empty and try rebooting to single user mode. If
> > the file /tmp/rc.test.txt has "rc.local has run" in it, then it ran;
> > otherwise not. rc.local does definitely run at normal multiuser console
> > and graphics mode.
> >
> > D. Stimits, [EMAIL PROTECTED]
>
> This command will tell you in which runlevels rc.local
> will be executed:
>
> ls -l /etc/rc.d/*/*local*
>
> The sequence of actions during startup is the following:
> the init program /sbin/init will load a configuration
> file from /etc/inittab. The configuration file will tell
> init to execute /etc/rc.d/rc, this script will execute
> all start scripts from the appropriate runlevel directory.
>
> --
> Kasper Dupont
At first I had not noticed that rc.local was itself called from the same
rc symbolic links. The difference is that most daemons and other items
that are started this way are pointed to in the init.d subdirectory,
whereas rc.local is linked to directly in the parent. This appears to be
enough to keep it out of the usual chkconfig --list display.
D. Stimits, [EMAIL PROTECTED]
------------------------------
Date: Fri, 04 May 2001 02:03:10 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hot plug PCI device
Mulder wrote:
>
> Hi,
>
> I am developing a PCI card and its Linux driver as well.
> There is a PCI protection card between PCI bus and my PCI card.
> The PCI protection card can turn my PCI card on/off when PC is ON.
>
> When PC is booted into Linux with this PCI card on,
> I can see this card's resource in /proc/pci and access it.
> To save reboot time, if I found some H/W bugs, I'd like to turn off the
> power
> to this card, removed it from the PCI protection card, fix the H/W bugs,
> re-plugget it to the PCI protection card, and turn off the power to this
> card.
> After this routine, I still can see this card's in /proc/pci.
> However, this card can't be accessed correctly now.
> All read returns 0xFFFFFFFF.
>
> How can I debug the H/W of a PCI card without rebooting PC ?
>
> Thanks!
I don't know the answer, but one thing is obvious...all of the registers
and state in the PCI card is lost when you remove power, and needs to be
reinitialized. The kernel probably has to be told to reset all of its
ideas about this card and initialize it again. Don't ask me how you
would do it, I just think it is the problem to be solved (perhaps the
pci init code could be duplicated in a second program that is manually
called).
D. Stimits, [EMAIL PROTECTED]
------------------------------
Date: Fri, 04 May 2001 02:06:02 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: STLport 4.0 & g++ 2.96
Steve Connet wrote:
>
> I'm using Linux kernel 2.2.16-22 & RH7.0. Not sure where else to ask
> this question so if it's off topic, kindly direct me to the correct
> forum.
>
> I am trying to compile the STLport4.0 with g++ 2.96. I get to a file
> called money_put_w.cpp and I get the following:
>
> c++ -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
>-ftemplate-depth-32 -g -fPIC money_put_w.cpp -c -o obj/GCC/DebugD/money_put_w.o
> c++: Internal error: Segmentation fault (program cpp0)
> Please submit a full bug report.
> See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
> make: *** [obj/GCC/DebugD/money_put_w.o] Error 1
> [sconnet@rigel]/usr/devel/STLport-4.0/src>
>
> I understand reverting back to g++ 2.95 is next to impossible since
> everything on my system is compiled with 2.96??
>
> Any ideas would be appreciated. The only other compiler I have is
> egcs-2.91.66.
>
> --
> Steve Connet Remove USENET to reply via email
> [EMAIL PROTECTED]
It isn't unusual to see an error similar to that when a template is told
to work with a data type that it does not know about (such as because it
is missing the right include file to understand that type). Check to be
sure that any type the template is told to use has its definition
available to the templates.
D. Stimits, [EMAIL PROTECTED]
------------------------------
From: Torsten Blank <[EMAIL PROTECTED]>
Subject: Re: malloc Bug?
Date: 04 May 2001 10:06:08 +0200
[EMAIL PROTECTED] writes:
> Torsten Blank <[EMAIL PROTECTED]> wrote:
>
> > Oh, i think i was too fast. Nothing has changed with "echo 1 >
> > /proc/sys/vm/overcommit_memory".
>
> It looks as if overcommitment was switched on already - try setting it to
> 0 and run your program again (I assume that you don't really have 2.8 GB
> of memory). If the comtent of /proc/sys/vm/overcommit_memory doesn't change
> when you echo 1 or 0 into it you may have to recompile your kernel to allow
> run time changes of kernel parameter.
Everything works with sysctrl, but changing the parameter shows no
effect. You can try it. I will append the test program (speichertest)
at the end of this mail.
-> "cat /proc/sys/vm/overcommit_memory" shows:
0
-> "free" shows:
total used free shared buffers cached
Mem: 130660 125464 5196 0 27796 42864
-/+ buffers/cache: 54804 75856
Swap: 273024 34468 238556
-> "speichertest 100" shows:
speichertest: Blocksize = 100 MByte
memsize = 100 MByte ptr = 40101008
memsize = 200 MByte ptr = 46502008
memsize = 300 MByte ptr = 4c903008
memsize = 400 MByte ptr = 52d04008
memsize = 500 MByte ptr = 59105008
memsize = 600 MByte ptr = 5f506008
memsize = 700 MByte ptr = 65907008
memsize = 800 MByte ptr = 6bd08008
memsize = 900 MByte ptr = 72109008
memsize = 1000 MByte ptr = 7850a008
memsize = 1100 MByte ptr = 7e90b008
memsize = 1200 MByte ptr = 84d0c008
memsize = 1300 MByte ptr = 8b10d008
memsize = 1400 MByte ptr = 9150e008
memsize = 1500 MByte ptr = 9790f008
memsize = 1600 MByte ptr = 9dd10008
memsize = 1700 MByte ptr = a4111008
memsize = 1800 MByte ptr = aa512008
memsize = 1900 MByte ptr = b0913008
memsize = 2000 MByte ptr = b6d14008
memsize = 2100 MByte ptr = 80496f0
memsize = 2200 MByte ptr = e4496f8
memsize = 2300 MByte ptr = 14849700
memsize = 2400 MByte ptr = 1ac49708
memsize = 2500 MByte ptr = 21049710
memsize = 2600 MByte ptr = 27449718
memsize = 2700 MByte ptr = 2d849720
memsize = 2800 MByte ptr = 33c49728
=================== cut =========================
/* speichertest.c -- Torsten Blank Fri Nov 3 2000 */
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
int blocksize = 1;
int bytes;
int *ptr;
int memsize = 0;
int s;
if(argc >= 2)
blocksize = atoi(argv[1]);
printf("speichertest: Blocksize = %d MByte\n\n",blocksize);
bytes = blocksize*1024*1024;
while(ptr = malloc(bytes)){
memsize += blocksize;
printf("memsize = %d MByte\t ptr = %x\n",memsize,ptr);
}
return 0;
}
=================== cut =========================
--
Torsten Blank
Institut fuer Theoretische Physik der Uni Karlsruhe
Tel: 0721 / 608 6365 Fax: 0721 / 608 3582
Web: http://www-itp.physik.uni-karlsruhe.de/~tb
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
