Linux-Development-Sys Digest #274, Volume #8 Mon, 13 Nov 00 01:13:13 EST
Contents:
Measuring CPU Cache Performance (Kent A Vander Velden)
load/unload module dinamically -- help -- ("Arnaud FRANCQ")
Re: Socket accept signedness in G++ (Juergen Heinzl)
Re: Socket accept signedness in G++ (Juergen Heinzl)
Tapping into current resource ([EMAIL PROTECTED])
Re: No swap activity. ("Patrick \"The King of Finchland\" Finch")
Re: No swap activity. ("Patrick \"The King of Finchland\" Finch")
Re: No swap activity. (Taavo)
Re: No swap activity. ("Patrick \"The King of Finchland\" Finch")
Re: No swap activity. ("D. Stimits")
Re: No swap activity. ("D. Stimits")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kent A Vander Velden)
Subject: Measuring CPU Cache Performance
Date: 12 Nov 2000 20:43:10 GMT
Is there a way with Linux and PentiumII+ to measure the cache performance
of the CPU? I would like to know if my application is being greatly affected
by cache misses.
Thanks.
--
Kent Vander Velden
[EMAIL PROTECTED]
------------------------------
From: "Arnaud FRANCQ" <[EMAIL PROTECTED]>
Subject: load/unload module dinamically -- help --
Date: Sun, 12 Nov 2000 21:18:13 GMT
I've written an application using PAM that authenticate user with smart
card. My app access the smart card reader via a driver (module). I want that
module to be load dynamically by my app when access to reader is needed and
then unloaded when access is not needed (by system or by my app after
treatment).
Another problem occur... kernel send message smcmgr.o : unresolved symbol
...
I don't know what it means ? Anyway, my driver works properly ??
Can U please help me ???
Arnaud FRANCQ
French linux user
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Date: 12 Nov 2000 22:48:29 GMT
In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>On 12 Nov 2000 00:33:08 GMT, Juergen Heinzl <[EMAIL PROTECTED]>
>wrote:
>>In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>>>On 11 Nov 2000 00:10:47 GMT, Juergen Heinzl <[EMAIL PROTECTED]>
>>>wrote:
>>>>In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>>>>>On Fri, 10 Nov 2000 18:22:02 +0000, Christoper McClan <[EMAIL PROTECTED]>
>>>>>wrote:
>>>>>>
>>>>>>I'm doing some fairly standard socket programming, and one piece of
>>>>>>code contains the line :
>>>>>>
>>>>>>client_sockfd = accept(server_sockfd,(struct sockaddr *)&client_address\
>>>>>>, &client_len);
>>>>>>
>>>>>>The variables and such are defined as you would expect. It compiles
>>>>>>fine with gcc, but when compiling with g++, I get the following error :
>>>>>
>>>>>If by ``compile fine'' you mean ``I get a few warnings related to ANSI C
>>>>>constraint rule violations, but I will ignore them''. ;)
>>>>>
>>>>>>server.c: In function `int main()':
>>>>>>server.c:40: passing `int *' as argument 3 of `accept(int, sockaddr *\
>>>>>>, socklen_t *)' changes signedness
>>>>>>
>>>>>>(Obviously I have inserted the '\' character).
>>>>>>
>>>>>>Any ideas?
>>>>>
>>>>>Yes, you must pass a ``socklen_t *'' value as the third argument. The Single
>>>>>UNIX specification has introduced this absurd ``socklen_t'' type which
>>>>>represents the length of an address, and required that it must be some unsigned
>>>>>type, thus breaking all legacy code which uses the type int.
>>>>[-]
>>>>I've seen machines where socklen_t can be 4 *or* 8 byte, depending on
>>>>how you compile the code and for reasons.
>>>
>>>Or, more likely, the type int can be 4 or 8 bytes, with socklent_t probably
>>>having to be defined so that its size stays the same for the ABI? Is
>>>that what you are thinking of?
>>[-]
>>
>>I'm thinking of not caring what size socklen_t is compared to the size
>>of an int and no, it does not need to have the same size.
>>
>>Using int and thinking it'd be okay is an assumptions -- computers are
>>stupid though, they don't like assumptions.
>
>Then why don't we have a typedef for POSIX file descriptors instead of using
>int? Why don't we have an argcount_t symbol for argc in the main() function?
[-]
We're talking about socklen_t -- nothing else. Sure let's argue why this
and why not that, but I'm off then.
[-]
>The answer is that for some things you just don't need to create useless,
>phony abstractions.
>
>If you want to represent the size of an object, C gives you a type: size_t.
>It would have made sense to use a pointer to size_t as the third parameter of
>accept() rather than inventing yet another way to specify sizes.
[-]
socklen_t is the size of some address. An object is a different thing to
me and right here speaking about an object you've introduced an abstraction.
Even an int is an abstraction as no-one cares much about it's bit pattern
or byte ordering if he/she does not have to.
>
>Here is a question: why is it okay to use an ``int *'' in the interface
>of pthread_attr_getschedpolicy? Why doesn't it suffer from the same ailment
>that accept() was diagnosed with, and thus require the same cure?
[-]
Using pthread's is a mess given the number of slightly varying versions
so yes, but again what does this have to do with socklen_t ?
>
>>>>socklen_t isn't that absurd even though people love to say so (gracefully
>>>>ignoring Linus' opinion regarding socklen_t here, yep).
>>>
>>>It's absurd because
>>>
>>>- the standard requires it to be unsigned, whereas all traditional UNIX
>>> code uses the type int. Without that requirement, implementors could just
>>> typedef int socklen_t, should they wish to do so.
>>[-]
>>Never mind, so we ought to use K&R C because ANSI or C99 breaks traditional
>>code ?
>
>ANSI C and C99 plug holes in useful ways. For example C99 no longer allows
>implicit function declarations, and implicit int. This breaks legacy programs
>which are of a dubious quality. And note that these features were made
>obsolescent first! Whereas I'm not aware that the change to accept's interface
>was preceded by an obsolescence phase; it was just dumped on programmers.
[-]
Yes, good point but while just dumping something on someone is bad politics
it says nothing about the usefulness of socklen_t.
>There is nothing dubious about using ``int *'' as the third parameter of
>accept(). It's a perfectly safe, well-understood interface that was granted and
>then gratuitously broken, probably because some vendor had some stupid problem
>and wanted to make it everyone else's.
[-]
Either to be continued in alt.conspiracy or show me which vendor it was
and I'll shut up on the spot, big promise.
>>>- you don't need a big honking typedef to represent the length of something
>>> that is unlikely to ever reach a two digit figure in the forseeable future.
>>[-]
>>I don't care what size socklen_t is of in an actual implementation, really.
>
>Equally, I don't care what the size of int is on an actual implementation. But
>I know that if I declare one of these puppies, I can call
>pthread_attr_getschedparam to store something in it and it will work
>in all kinds of POSIX environments.
>
>>>- As a source level construct, it does nothing for binary compatibility. E.g.
>>> 32 bit *binary* applications, perhaps compiled even before socklen_t
>>> existed, running over a 64 bit library and kernel.
>>[-]
>>A 32 bit binary may be compiled to use a 64 bit socklen_t -- there goes
>>your "int is fine" in new code.
>
>If that 32 bit binary uses int *, then it won't necessarily compile because
>of the interface change.
>
>I'm talking about old binaries that are *not* recompiled, and which
>therefore depend on the old ABI of accept, pthread_attr_getschedparam
>and other functions, which use pointers to 32 bit objects.
[-]
I don't see the problem, really. Usually API changes can be hidden in most
cases so old binaries can run quite fine for a long time.
>If these binaries can continue to function, then so can newly written code
>which makes the same assumption. Thus a compiler switch can be provided to
>support this new code, or new builds of old code: the switch makes int 32 bits
>wide, and links in the appropriate library whose accept() and
>pthread_attr_getschedparam() store a 4 byte object through the int *.
[-]
Great idea as then all compilers on all machines having adopted that new
API standard need to be updated and of course there needs to be a switch
for each and every API change that might break traditional code.
[-]
>>[-]
>>You don't need such libraries on systems that support versioning like
>>Solaris or Linux nowadays, so problem solved as far as old binaries are
>>concerned. At least for some time into the future, that is.
>
>Well, you'd have to version a heck of a lot of symbols and end up with a
>bloated library. You will find that the GNU libc developers, for instance, are
>quite resistant to adding any new versioned symbols. It is done only when
>absolutely necessary. I remember submitting one patch not long ago, upon which
>was told to fix it to use spare bits in an existing struct member rather than
>extend it with a new member and add versioning to a couple of functions.
>
>Versioning adds bloat because you have both versions of the same function in
>the same module. Unless they are rearranged in the linker, you degrade the
>locality of reference; more pages of the resulting have to be faulted in.
>Moreover, if both versions of the function are in the same codebase, things get
>messy. Every type is declared twice for each ABI. I suspect that symbol
>versioning isn't really suitable for wholesale ABI migration.
[-]
Yes, versioning adds bloat and should be avoided, sure thing. Still lacking
even one conclusive argument that would be valid for each and every API out
there now and in the foreseeable future. I'm definitely not convinced yet
and while I do agree the introduction of socklen_t was a compromise at best
socklen_t seems to me just "problem" constantly blown out of proportions
and beaten to death for fun and amusement more than anything else.
Ta',
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Date: 12 Nov 2000 22:48:29 GMT
In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>On 12 Nov 2000 00:33:14 GMT, Juergen Heinzl <[EMAIL PROTECTED]>
>wrote:
>>Sorry, but if one cannot give it a value then socklen_t would not
>>be usable at all. I've written code using socklen_t not only on
>>Linux and can assure you giving it a value using sizeof() always
>>compiled and worked like a charm.
>
>Why wouldn't it? Name one C integral type, signed or unsigned, (other than a
>bitfield) which cannot represent the size of a network address. Your choice of
>network, but it has to exist. ;)
[-]
Can't answer the question since the statement leading to my reply left me
in a state of ongoing confusion too.
------------------------------
From: [EMAIL PROTECTED]
Subject: Tapping into current resource
Date: Mon, 13 Nov 2000 01:31:53 GMT
I am in the middle of an upgrade of the server room and I need to know
of the page fault handlers that are embedded within the kernel, namely
system functions. I would like to monitor the load of the processes that
the system incurs, so I would like to somehow tap into an existing sys
function that will provide the information I need. More importantly, I
would need to be able to track the page faults due to a specific process
as well as due to the entire system. This would tremendously help me out
since efficiency is a primary factor in my setup. Thanks a lot.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Patrick \"The King of Finchland\" Finch" <[EMAIL PROTECTED]>
Subject: Re: No swap activity.
Date: Sun, 12 Nov 2000 18:01:27 -0800
I should have included this originally, sorry.
Filename Type Size Used Priority
/dev/sdc6 partition 265032 0 1
/dev/sdb6 partition 265032 0 1
The box is now using 490 M of RAM + or - a few meg....
There seems to be a memory leak somewhere I suppose. The RAM usage keeps
going up until all o fthe RAM is used. From watching top I see used memory
go up a few megs, then back down, however it seems to go down less than it
goes up..... which eventually causes it to use all of the physical
memory.....
I once saw a posting about the 2.4 kernels not swapping reliably becuase of
some piece of code. If that piece of code were commented out then the
computer swaps aggresively (which is not good) but between giving up some
performance becuase of aggresive swapping, and crashing, I think I would
rather give up some performance...
Have any of you seen the post I am talking about... Damn, I wish I could
find it again.
Thanks
pat
>What does /proc/swaps tell you?
>
>--
>Paul Kimoto
>This message was originally posted on Usenet in plain text. Any images,
>hyperlinks, or the like shown here have been added without my consent,
>and may be a violation of international copyright law.
------------------------------
From: "Patrick \"The King of Finchland\" Finch" <[EMAIL PROTECTED]>
Subject: Re: No swap activity.
Date: Sun, 12 Nov 2000 18:06:01 -0800
Well I should have included this with the first post...
Filename Type Size Used Priority
/dev/sdc6 partition 265032 0 1
/dev/sdb6 partition 265032 0 1
The box is now using 490 M of RAM and still no swap....
There seems to be a memory leak somewhere I suppose becuase it keeps using
more and more RAM. It will take up 3 megs of memory, then give back only
like 2.5 or so....
Thanks
pat
p.s.
I hope I am not triple posting this, I've been having some news
problems..... errrrrrr
>What does /proc/swaps tell you?
>
>--
>Paul Kimoto
>This message was originally posted on Usenet in plain text. Any images,
>hyperlinks, or the like shown here have been added without my consent,
>and may be a violation of international copyright law.
------------------------------
From: Taavo <[EMAIL PROTECTED]>
Subject: Re: No swap activity.
Date: Sun, 12 Nov 2000 21:38:16 -0500
Patrick \"The King of Finchland\" Finch wrote:
> I should have included this originally, sorry.
>
> Filename Type Size Used Priority
> /dev/sdc6 partition 265032 0 1
> /dev/sdb6 partition 265032 0 1
>
> The box is now using 490 M of RAM + or - a few meg....
>
> There seems to be a memory leak somewhere I suppose. The RAM usage keeps
> going up until all o fthe RAM is used.
My understanding on this is it is quite normal to see the # of bytes free
memory decrease to a small value (e.g. on the order of 2-5 Megs). This is
because the kernel will take any memory that is not currently needed by
processes, and use it for a buffer cache, mostly for disk reads. Therefore, as
you use the system and R/W more and more files, these are buffered using any
free memory. The kernel will do this until it approaches a small free value.
If there is memory required for a process, the kernel will free some part of
this buffer cache using a LRU like algorithm to drop the most un-needed pages
of buffer cache. The buffer cache is kept current -- new reads may overwrite
old pages. This is simply the kernel making the most efficient use of the
physical mem and resources of your machine.
>From my system:
total used free shared buffers cached
Mem: 128268 125272 2996 8288 5316 104704
-/+ buffers/cache: 15252 113016
Swap: 136544 2964 133580
As you can see, there is very little free memory -- but look at how much is
used by the cache.
> From watching top I see used memory
> go up a few megs, then back down, however it seems to go down less than it
> goes up..... which eventually causes it to use all of the physical
> memory.....
So, it is quite normal to see nearly all the phy memory used when you do the
'free' command.
A memory leak will typically manifest itself as a process that is using a
growing amount of memory. You can see this easily by using the top or the ps
command.
With 512 MB phy memory, I wouldn't expect to see a whole lot of swapping. How
much memory is being used by your largest processes, e.g. that apache server w/
120 clients?
At any rate, running out of virtual memory should cause the process to die, not
the box to crash. Is that what you are experiencing?
Taavo.
------------------------------
From: "Patrick \"The King of Finchland\" Finch" <[EMAIL PROTECTED]>
Subject: Re: No swap activity.
Date: Sun, 12 Nov 2000 20:29:16 -0800
>A memory leak will typically manifest itself as a process that is using a
>growing amount of memory. You can see this easily by using the top or the
ps
>command.
>
>With 512 MB phy memory, I wouldn't expect to see a whole lot of swapping.
How
>much memory is being used by your largest processes, e.g. that apache
server w/
>120 clients?
>
Each server started by apache takes up about 7 megs of memory, right now it
starts 10 servers, and keeps 10 servers around (MinSpareServers) just in
case, in the last day it hasn't hit the MaxClients setting of 120... Each
apache process never really grows, so apache seems to be alright, apache
seems to be the only thing really using any significant amount of RAM, other
than mysqld (which doesn't get a lot of usage).
>At any rate, running out of virtual memory should cause the process to die,
not
>the box to crash. Is that what you are experiencing?
What was happening was this:
The box would have a few days to a month of uptime and the physical
memory usage would be around 508 or so, I still saw no swap and that's when
I started to get worried. Eventually, the box would start slowing down, and
I would start looking for processes to kill.... After a minute or so, the
box would lock up, and not respond to any network requests which would cause
me to go to the terminal and see what was going on. If I stayed at teh
terminal for too long, the box would stop responding to requests from the
terminal, and I ended up reooting the machine, I have seen this happen three
times in 2 or so months and it was really starting to irk me.
Thanks for the help (and the great explanation)
pat
------------------------------
Date: Sun, 12 Nov 2000 22:13:58 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: No swap activity.
Wouter Verhelst wrote:
>
> In article <8ulp6j$74j7$[EMAIL PROTECTED]>,
> "Patrick \"The King of Finchland\" Finch" <[EMAIL PROTECTED]> writes:
> > Howdy all
> >
> > Well, heres the problem
> >
> > My linux box won't swap. This is actually getting me kinda worried.
> > Anyway, here is the history.
> >
> > Hardware--
> > Compaq Proliant 2500R
> > 512 M RAM
> > 3 9.1 gig scsi drives (the hot pluggables)
>
> Wild guess:
>
> Is it possible that swapspace needs to be on disks that are *NOT* hot
> pluggable?
>
> I wouldn't know, I don't have hot pluggable hardware ;-)
Backplanes that survive warm or hot-pluggable (hot implies software to
deal with changing the device while running, warm implies it won't harm
the device physically, but software may be corrupted) won't harm the
ability to swap at all.
>
> <snip>
>
> HTH, HAND
>
> --
> wouter punt verhelst op advalvas in Belgi�
> 7:53pm up 5:57, 2 users, load average: 1.03, 1.06, 1.13
> Voor een vertaling van Documentation/Configure.help naar het Nederlands:
> http://users.pandora.be/wouter.verhelst/configure.html
>
> "You don't go out and kick a mad dog. If you have a mad dog with rabies, you
> take a gun and shoot him."
> -- Pat Robertson, TV Evangelist, about Muammar Kadhafy
------------------------------
Date: Sun, 12 Nov 2000 22:16:15 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: No swap activity.
By what means have you determined it isn't swapping? Is it locking up as
it uses up ram? Using up all ram when there is no swap is fatal.
Patrick \"The King of Finchland\" Finch wrote:
>
> Howdy all
>
> Well, heres the problem
>
> My linux box won't swap. This is actually getting me kinda worried.
> Anyway, here is the history.
>
> Hardware--
> Compaq Proliant 2500R
> 512 M RAM
> 3 9.1 gig scsi drives (the hot pluggables)
> no "internal" storage
> Dual PPro 200
> no hot spare yet.....
> 2.4.0-test10
> software RAID 5
>
> / and /boot are on one disk, taking up 256 M of space.
> I have the other two disks configured with a 256 M swap partition each. In
> the fstab they are set as
> /dev/sdc6 swap swap defaults,pri=1 0 0
> /dev/sdb6 swap swap defaults,pri=1 0 0
>
> Now, no matter what I can't get this box to utilize any swap.
> I tried creating a swap file in /tmp, but it wouldn't swap to that
> either.....
>
> The logs don't seem to say anything, though I am not sure what to look for.
> However, i suspect this has been causing some system crashes. I had apache
> configured with the MaxClients = 120, then I realized that this machine
> wasn't swapping, and 120 instances of apache would use up all of it's
> memory...
>
> anyway, have any of you ever seen a problem like this?
> I would be very happy if the machine would just swap when it has to....
>
> Thanks
> pat
------------------------------
** 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
******************************
