[cod] Dr. D - This ones for you.
Jay Vasallo
jayco1 at charter.net
Sat Dec 18 17:25:57 EST 2004
Nice explanation Dr. D. Unfortunately, I am still sweeping floors and not painting ceiling as you are.
I have the game all loaded on the same partition.
Main game is loaded at /games/cod-server/uo
USER's are loctaed at /home/user/cod-server/uo
I only have a single server.cfg in the /home/user/cod-server/uo/server.cfg
I point to /games/cod-server as my executable directory because this is where the coduo_lnxded resides:
example: /games/cod-server/coduo_lnxded
Now I make the games/cod-server owned by admincliffy
I get that far...But still unsure about this linking process you are trying to explain. You say
" 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."
I say headache and start hitting the books. Can you demonstrate how you would link the user to :
/games/cod-server using this "mode 0x750" you refer to?
I would appreciate this.
=o)
----- Original Message -----
From: Mark J. DeFilippis
To: cod at icculus.org ; cod at icculus.org
Sent: Saturday, December 18, 2004 3:58 PM
Subject: Re: [cod] Dr. D - This ones for you.
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/562af3f9/attachment.htm>
More information about the Cod
mailing list