[cod] Dr. D - This ones for you.

[Mark J. DeFilippis]

Recently some updates were brought to my attention with
regards to the sticky bit, and memory utilization (mbuf allocation),
and I did a little research...

The current writing referenced by many on this forum, is more semantics
than anything else.  Dating back prior to Unix V.3, Memory was very
expensive. Hence, there was not often enough memory to keep all executable
(text) pages in memory, and in severe cases, entire programs were swapped in
and out, text pages were more often paged in and out as the CPU ran out of
text to execute on behalf of a program.  The CPU would request text code be
read from swap, halt the program, put it on the I/O stack (waiting I/O), 
and move
on to the next program for a set period of time, for CPU allocation.  When the
I/O was performed asynchronously, and the text copied in to memory, the program
put in Wait I/O state" was put in "Runnable state".  Cpu would then 
continue execution.

As memory became cheaper, Unix systems were able to store more text pages
in RAM, and in fact, you based your memory purchase on how large the 
applications
were going to be for the user base. This way you could assure that all code 
could fit
in memory, and hence Page swapping and Text page swapin, swapout was a 
No-No, and
a execution killer. (Today, these swap variables still exist in vmstat, as 
it is not
impossible to begin swapping text pages, and full page swapping is just not 
done.

Today, with cheap ram, and faster disks, executable text is not even copied 
to SWAP
anymore, since the executable code is made of two parts.. The local text 
portion of the
code, and the shared link libraries reference.  Between memory size, and 
buffer sizes
entire application text pages are loaded.  No more swapping, no more paging 
text pages,
no more load from swap, so the sticky bit is irrelevant.

In reality, this was really the case under systems as old as Unix V.3.2 as 
Unix moved
to the Intel platform.  When we designed applications, we made sure there 
was always
enough ram. A paging program is a "slow program".  Gaming is much more 
sensitive
as you know.

Today, shared link libraries are loaded once. Your text code (The portion 
that is not
global link library based) is loaded in to ram. However, please note, thing 
have not
changed in relation to the memory usage for multiple copies of a program!

If you load 7 copies of the executable, and the executables all have different
inodes, Linux has no way of knowing any two executables are the same,
hence it WILL load multiple copies in to ram. This can be seen.

If you link them, they will all have the same inode value. Linux will load
the code once using the same text pointers when executing. So there is
still value in using links to the same inode when invoking the same program
multiple times!


In your specific case, I am assuming from the alternate path, that the 
executables
are on one partition, and the users homes on another.  If you link across file
systems, of course Linux will make a copy, and all will have separate inode
values, and you are SOL.  This of course consumes more memory, and more disk.
Likely no big deal on disk, but memory is still expensive to lease on servers!
($50/mo from 1-2GB upgrade is a lot).

If I were in your shoes, I would make a local copy of the executable owned by
the admin name whatever it is (not hopefully root), and link it to each users
directory.  The users would be in the same GID.  You should make the executable
mode 0x750, and owned by the admin, group GID, so it is RWX by you the admin,
while it is only readable and executable, but not writable by the Group of 
users with
group GID. There is no need for it to be.

You get to take advantage of the same inode value which is still more 
efficient in
virtual machine based OS's today in it's memory utilization.. such as Linux.

If you think about it, it really makes sense.  Linux knows nothing from 
filenames.
It knows Inode numbers (or index hash values in to the file descriptor block.
Same inode, it knows is same file, same code text.  Different inode, it knows
nothing that the two programs running in memory are the same code...

This is what I would do. I would expect largely many of the server admins 
do indeed
have their virtual server hosting set up similarly when it comes to the COD 
executable...

I hope this help.  My thanks to those that pointed at the recent updates to 
mbuf()
allocation via malloc(), and kernel references.

Dr. D


At 10:45 AM 12/17/2004, Jay Vasallo wrote:
>OK, How do I do this usuing your method?
>
>
>----- Original Message ----- From: "Jay Vasallo" <jayco1 at charter.net>
>To: <cod at icculus.org>
>Sent: Friday, December 17, 2004 9:30 AM
>Subject: [cod] Dr. D - This ones for you.
>
>
>>Dr. D Wrote:
>>
>>"Because 10 servers your way will load 10 copies in to swap, 10
>>copies in to memory, etc.  Using the method of symlinks, which
>>is really nothing more than a link in the super block.  The super block
>>maintains all information about which disk blocks belong tio which
>>files.  For your simlink the new file entry simply gets the same
>>inode id copied to the table.  Same inode, same code... With
>>shared libraries in memory,  for the 10 servers only 1 copy
>>exists in swap. Only 1 copy exists in memory.
>>
>>I hope this is more clear."
>>
>>Dr. D
>>
>>
>>Can you please explain this a little further:
>>Lets say I have my games in:
>>/games/cod-server/coduo_lxded
>>and the useres at:
>>/home/user/cod-server/uo
>>
>>
>>How does help this help this situation.
>>
>>Thanks =o)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>----- Original Message ----- From: "Luke Antins (Firestorm Games)" 
>><luke at firestorm-games.net>
>>To: <cod at icculus.org>
>>Sent: Friday, December 17, 2004 12:15 AM
>>Subject: Re: [cod] COD 1.5 Patch is out! (any news on the linux server?)
>>
>>
>>Hi Ryan.
>>
>>Thanks for the update! Its much appreciated.
>>When you say Friday, do you mean this Friday? (ie today for us in Europe) 
>>17/12/2004 or do you mean 24/12/2004.
>>
>>Just want to make sure because of the timezones ;¬)
>>
>>Kind Regards
>>Luke Antins
>>--
>>[Firestorm Games]
>>http://www.firestorm-games.net/
>>
>>On Fri, 17 Dec 2004, Ryan C. Gordon wrote:
>>
>>>
>>>>Anyone have any idea when the Linux server will be out?
>>>
>>>As early as Friday, I hope. It was supposed to be simultaneous, but we ran
>>>into a last-minute snag with a pure-server issue and the Windows version got
>>>shipped anyhow...mostly we're just juggling data files around to get the
>>>packages to match up at this point.
>>>
>>>--ryan.
>>>
>>
>>
>

S1-------------------------------------------------------------------------------
Mark J. DeFilippis, Ph. D EE          defilm at acm.org
                                       defilm at ieee.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20041218/5ac0c699/attachment.htm>