<html>
<body>
<br>
Recently some updates were brought to my attention with<br>
regards to the sticky bit, and memory utilization (mbuf
allocation),<br>
and I did a little research...<br><br>
The current writing referenced by many on this forum, is more
semantics<br>
than anything else. Dating back prior to Unix V.3, Memory was
very<br>
expensive. Hence, there was not often enough memory to keep all
executable<br>
(text) pages in memory, and in severe cases, entire programs were swapped
in<br>
and out, text pages were more often paged in and out as the CPU ran out
of<br>
text to execute on behalf of a program. The CPU would request text
code be<br>
read from swap, halt the program, put it on the I/O stack (waiting I/O),
and move<br>
on to the next program for a set period of time, for CPU
allocation. When the<br>
I/O was performed asynchronously, and the text copied in to memory, the
program<br>
put in Wait I/O state" was put in "Runnable state".
Cpu would then continue execution.<br><br>
As memory became cheaper, Unix systems were able to store more text
pages<br>
in RAM, and in fact, you based your memory purchase on how large the
applications<br>
were going to be for the user base. This way you could assure that all
code could fit<br>
in memory, and hence Page swapping and Text page swapin, swapout was a
No-No, and<br>
a execution killer. (Today, these swap variables still exist in vmstat,
as it is not<br>
impossible to begin swapping text pages, and full page swapping is just
not done.<br><br>
Today, with cheap ram, and faster disks, executable text is not even
copied to SWAP<br>
anymore, since the executable code is made of two parts.. The local text
portion of the<br>
code, and the shared link libraries reference. Between memory size,
and buffer sizes<br>
entire application text pages are loaded. No more swapping, no more
paging text pages,<br>
no more load from swap, so the sticky bit is irrelevant.<br><br>
In reality, this was really the case under systems as old as Unix V.3.2
as Unix moved<br>
to the Intel platform. When we designed applications, we made sure
there was always<br>
enough ram. A paging program is a "slow program". Gaming
is much more sensitive<br>
as you know.<br><br>
Today, shared link libraries are loaded once. Your text code (The portion
that is not<br>
global link library based) is loaded in to ram. However, please note,
thing have not<br>
changed in relation to the memory usage for multiple copies of a
program!<br><br>
If you load 7 copies of the executable, and the executables all have
different<br>
inodes, Linux has no way of knowing any two executables are the
same,<br>
hence it WILL load multiple copies in to ram. This can be seen.<br><br>
If you link them, they will all have the same inode value. Linux will
load<br>
the code once using the same text pointers when executing. So there
is<br>
still value in using links to the same inode when invoking the same
program<br>
multiple times!<br><br>
<br>
In your specific case, I am assuming from the alternate path, that the
executables<br>
are on one partition, and the users homes on another. If you link
across file<br>
systems, of course Linux will make a copy, and all will have separate
inode<br>
values, and you are SOL. This of course consumes more memory, and
more disk.<br>
Likely no big deal on disk, but memory is still expensive to lease on
servers!<br>
($50/mo from 1-2GB upgrade is a lot).<br><br>
If I were in your shoes, I would make a local copy of the executable
owned by<br>
the admin name whatever it is (not hopefully root), and link it to each
users<br>
directory. The users would be in the same GID. You should
make the executable<br>
mode 0x750, and owned by the admin, group GID, so it is RWX by you the
admin, <br>
while it is only readable and executable, but not writable by the Group
of users with<br>
group GID. There is no need for it to be.<br><br>
You get to take advantage of the same inode value which is still more
efficient in<br>
virtual machine based OS's today in it's memory utilization.. such as
Linux.<br><br>
If you think about it, it really makes sense. Linux knows nothing
from filenames.<br>
It knows Inode numbers (or index hash values in to the file descriptor
block.<br>
Same inode, it knows is same file, same code text. Different inode,
it knows<br>
nothing that the two programs running in memory are the same
code...<br><br>
This is what I would do. I would expect largely many of the server admins
do indeed<br>
have their virtual server hosting set up similarly when it comes to the
COD executable...<br><br>
I hope this help. My thanks to those that pointed at the recent
updates to mbuf()<br>
allocation via malloc(), and kernel references.<br><br>
Dr. D<br><br>
<br>
At 10:45 AM 12/17/2004, Jay Vasallo wrote:<br>
<blockquote type=cite class=cite cite>OK, How do I do this usuing your
method?<br><br>
<br>
----- Original Message ----- From: "Jay Vasallo"
<jayco1@charter.net><br>
To: <cod@icculus.org><br>
Sent: Friday, December 17, 2004 9:30 AM<br>
Subject: [cod] Dr. D - This ones for you.<br><br>
<br>
<blockquote type=cite class=cite cite>Dr. D Wrote:<br><br>
"Because 10 servers your way will load 10 copies in to swap,
10<br>
copies in to memory, etc. Using the method of symlinks, which<br>
is really nothing more than a link in the super block. The super
block<br>
maintains all information about which disk blocks belong tio which<br>
files. For your simlink the new file entry simply gets the
same<br>
inode id copied to the table. Same inode, same code... With<br>
shared libraries in memory, for the 10 servers only 1 copy<br>
exists in swap. Only 1 copy exists in memory.<br><br>
I hope this is more clear."<br><br>
Dr. D<br><br>
<br>
Can you please explain this a little further:<br>
Lets say I have my games in:<br>
/games/cod-server/coduo_lxded<br>
and the useres at:<br>
/home/user/cod-server/uo<br><br>
<br>
How does help this help this situation.<br><br>
Thanks =o)<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br>
----- Original Message ----- From: "Luke Antins (Firestorm
Games)" <luke@firestorm-games.net><br>
To: <cod@icculus.org><br>
Sent: Friday, December 17, 2004 12:15 AM<br>
Subject: Re: [cod] COD 1.5 Patch is out! (any news on the linux
server?)<br><br>
<br>
Hi Ryan.<br><br>
Thanks for the update! Its much appreciated.<br>
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.<br><br>
Just want to make sure because of the timezones ;¬)<br><br>
Kind Regards<br>
Luke Antins<br>
--<br>
[Firestorm Games]<br>
<a href="http://www.firestorm-games.net/" eudora="autourl">http://www.firestorm-games.net/</a><br><br>
On Fri, 17 Dec 2004, Ryan C. Gordon wrote:<br><br>
<blockquote type=cite class=cite cite><br>
<blockquote type=cite class=cite cite>Anyone have any idea when the Linux
server will be out?</blockquote><br>
As early as Friday, I hope. It was supposed to be simultaneous, but we
ran<br>
into a last-minute snag with a pure-server issue and the Windows version
got<br>
shipped anyhow...mostly we're just juggling data files around to get
the<br>
packages to match up at this point.<br><br>
--ryan.<br><br>
</blockquote><br><br>
</blockquote><br>
</blockquote>
<x-sigsep><p></x-sigsep>
<tt>S1-------------------------------------------------------------------------------<br>
Mark J. DeFilippis, Ph. D
EE
defilm@acm.org<br>
defilm@ieee.org<br><br>
<br>
</body>
</html>