javierco is right, and you're full of the proverbial bull's faeces.
little/big endian makes no difference to performance. if anything, for networking little endian are at a disadvantage to big-endian machines as the likes of htons(),ntohs() are not no-ops.
similarly, big-endian machines might have to byte-swap little-endian data formats. (eg ext2/3, etc.) and PCI is little-endian, so data to/from PCI cpu has to be byte-swapped, but that's arbitrary. there is no inherent performance advantage to either byte order.
also, some CPUs can use either byte order, eg MIPS.
that said, nearly everything, is little-endian, simply because of the prevalence of i386.
if you read the recent thread on l-k, it's because in private Linus has been talking for quite a while to the bitkeeper people about what he wanted from bitkeeper before he'd use it, and the bitkeeper people have gone and implemented most of it, so Linus agreed to use it for a while.
now that figure of 253 is not the real uptime. cause 2.2 i386 uptime rolls over after 498 days. so the real uptime is 751 days - 2 years 39 days. this machine was powered up before i was even working here, and i'm the 2nd longest serving admin.
that may a supporting reason, but actually the primary reason is due to concerns about EMR interfering with the aircraft systems.
eg, mobile phones: before they cracked down on their use, the pilots often would/hear/ phones negotiating with base stations in their headsets. (hold an active mobile near a radio or monitor sometime).
so in addition to banning mobile phones (use of or switched on) on flights, they've also cracked down on use of any electronic gear to be safe.
well, let's agree to differ about the right to whine then.
"If you ask me, YOU are a lot of the problem with Linux (off subject). Snooty GEEKS that can't stand to hear that Wind Blows might still have something up on Linux"
well, whether i'm a snooty geek or not is irrelevant, precisely because this is open-source and so anyone, be they non-snooty geeks or support companies who exist to give non-snooty support to users, have access to the code and can fully support you. as for caring about 'wind blows', i dont.:)
now, for non-snooty help: if you have an application that keeps crashing and you wish to investigate you can:
- run it under/attach to it with strace and see whether it crashes at the same point each time. ie:
strace -f programme
or
strace -f -p pid
- run under ltrace to trace library calls. often (especially with GUI software) the problem is with libraries and not the actual application.
syntax is similar to strace.
- run the application under gdb, or run gdb on the core file and get a 'backtrace' which is a 'history' of the calls immediately 'preceding' the crash. if you have a core file:
gdb -c corefile programme
you get a prompt. type in 'bt', a bunch of information should be printed out, copy this to an email and send it to the developer. to run the application from gdb
gdb programme arguments
you get a prompt. type 'run' to run the application. when it crashes you will be returned to the gdb prompt, type 'bt' to print the backtrace. again, mail that to the developer.
to quit from gdb: 'q'
and that's it..
NB: some distro's might set a system limit on corefiles, eg to 0 to prevent them altogether. use 'ulimit -c 100000000000' to remove the limit.
now, i'd/agree/ that stuff like the above would not be something your normal joe bloggs user would like to have to do, which is why companies like redhat develop things like bug-buddy. i dont see why this should be such a contraversial point either, why it should produce accusations of 'geek snootiness'. Those who can use the tools, should use them, those who cant need to have GUI tools written for them. the latter class will most likely be written by the distro suppliers as it is in their interest to make the product they are/selling/ as easy to use as possible.
With respect to your post, you didnt state that you had actually done anything about the problem. it's only now that you say you tried KDE's crash app. Open-Source is a double-edged sword, you get quality code for free, but in return when you encounter a problem you should at least try to do something to allow the developers of that application to fix the problem.
if every open-source user had the attitude of "uhhh.. it crashed.. linux still has a long way to go" and left it at that well then we might as well give up now. sorry, but as an open-source user you are almost obligated to do something about problems, ie at least report them. you are a/part/ of open-source even if you are not a developer.
(and before you call me snooty again, if you are a paying customer of a distribution vendor, then the obligation is on the distribution vendor. you have chosen for a business relationship, go whine at your vendor.:) ).
nice to see the moderators doing their best to make sure slashdot discussions are as bland as possible..
anyway, in answer to your comment:
"my internet access doesnt work"
i'd say: "did it crash? ok, run gdb on it, etc.. etc.."
redhat say: "just use our spiffy gnome setup tool"
that's why the likes of RedHat exist - precisely to make sure that normal users do not have to deal with insular zealots and do not have to get involved with debuggers. they get a pointy clicky tool that RedHat (or whoever) have made as fool proof as possible.
normal users -> catered to by distros
'zealots' -> catered to by the other zealots and developers
this guy/knows/ pppd is crashing on him, he at least should have enough gumption to be able to subscribe to a list or email a developer directly and ask for help (and hence maybe be asked "can you do the following.... gdb... bt..... ?")
linux on the desktop. i dont really care, neither do the people who write things like pppd daemons or kernel code. this is the domain of the companies who put together distributions.
(and i agree with the other poster that 'talkback' or 'bug-buddy' like stuff for system software would be useful.)
however, there is another machine running 2.4 that does get reasonably loaded at times, eg it often has context switch / second rates in the many thousands/sec for sustained periods of time. (highest seen this month so far 7873.12 c'switches/sec). it's a dual cpu 1GB compaq server. (the other was a uni proc, 128mb compaq server), and it's been up for 27 days so far with 2.4.9 - only 27 cause of a reboot due to an nfs problem (which was probably due to a mistake in firewalling).
2.4 does indeed have problems with corner cases. however, this is probably more of a problem for desktops than for servers that have admins paid to watch and tune them.
pppd keeps crashing? shame on those awful developers who gave you this piece of crashing software for free with source.
have you even made any attempt to try find out why it crashes? eg, run gdb on the core file and type in "bt" to get a backtrace, and send the output to the developers?
even enquired on any mailling lists about your problem? (and hence maybe come into contact with people who could have told you "get a backtrace and here's how you do it" if you didnt know it yourself).
there's nothing worse than people whining about problems with GPl or other open-source software. you can/do/ something about the problem! you could at the very/least/ report the problem!! otherwise dont whine.
directory_administrator which is a GNOME LDAP user admin tool (slick enough for use by a frontline helpdesk).
there are other LDAP GUI's, KDE has one. search freshmeat.
gq a general purpose LDAP GUI tool. quite slick, comes with RH7.x.
Also, note that with RH7, the 'passwd' tool uses pam and will hence automatically work with LDAP authentication. (presuming your LDAP server is configured correctly for write access).
finally, you'll probaby want to develop your own scripts with template LDIF's for things like useradd, or find someone who's already done so. (i noticed there's a post on this thread providing a link to exactly that.) Note that for scripting, PADL's migration scripts are very informative. These are included with the OpenLDAP distribution.
some databases (oracle and postgresql are 2 i know of) support BLOB data types. BLOB = Binary Large OBject, ie a big blob of data. you'd store your file contents in that.
de4x5 is DEC's own driver for the DE4x5, DE500-XX cards and the DE-2104x-XX and DE-2114x-XX chips. in addition any 3rd party card that use a DEC (or clone) 21{0,1}4x chipset and uses DEC's SROM format are supported.
(read the top of drivers/net/de4x5.c).
tulip is Donald Beckers driver. It is the newer of the 2, and supports more types of tulip cards/chipsets/srom formats than the Digital de4x5 driver does. It also was the more higher-performance and more 'linux' driver. however, the addition of support for every weird type of DE21x4x clone card has cruftified the tulip driver ever so slightly.
the Linux ABI is also very stable. the only thing that isn't guaranteed stable is extremely low-level linux-specific interfaces. (Eg firewalling, routing, network setup,/proc interfaces, etc..). Note that the most significant determinant of the stability of the ABI is/not/ the kernel, rather it is libc and libc++. (ie glibc for most linux systems.) If you have the right libraries you can still run 5 year old a.out binaries on linux 2.4.
the internal kernel API is not stable. and linus likes it that way.
xterms are about $400 to $600 new - not including monitor.
they're not cheap capital wise, the benefit is fire and forget, zero maintenance, less admins needed to tinker and care for workstations. (it breaks, just throw another in it's place).
"tainted" in this context means the kernel has had code loaded into it that the kernel developers can not support.
Eg, you load a vendor binary-only module (eg NVidia DRI module), the kernel developers can not debug any problems a user may have with that kernel as they do not have the source. Only NVidia can debug the problem fully.
It's not a matter of principles, it's a matter of practicality.
but, the violence in Northern Ireland over the last 25 years was as a direct result of Britains policies in Northern Ireland since the partitioning of Ireland in 1922.
There was institutional discrimination against the catholic community in Northern Ireland, and the govt in England turned a complete blind eye to it. In the 1960s unemployment amongst catholics was at 30 to 40%, while only at 10ish% for protestants. The Police force, business, the institutions of regional government were all dominated by the Protestant/Unionist community in Northern Ireland, and for the most part they used their power to oppress the catholic/nationalist minority. All with a blind eye turned by the UK government in England, or even it's approval.
So some of this oppressed minority people turned to violence. not a solution i would condone, but neither can you condone what went on in Northern Ireland post-WWII in the name of the United Kingdom.
Note that there also were many out of this community who tried peaceful means to change their plight. They'd hold peaceful civil rights marches. And they'd be met and beaten by the RUC, or on one occasion mown down by British paratroopers. (Bloody Sunday Jan 30 1972, Derry, 13 civilians shot dead by the Para's).
NI was a mess, a brutal mess and it produced some brutal people who committed some terrible acts. But the cause of it all was british actions and inaction.
there does seem to be light at the end tunnel now though. they've gotten it down to politicians throwing words at each other, rather than bombs.
however, this method will only work for physical link failures that are detected. (and i dont think linux does much even if it does detect a link failure).
needless to say the vast majority of network failures tend not to be detected link failures.
my suggestion would be to use OSPF for link state and route failure detection and failover.
I'll have a stab at this one... not all the details might be correct, but it should be close enough to get the idea..
VM is virtual memory. really in this context it should be: VMM, ie Virtual Memory Management.
VM refers to the fact that on modern processors memory addresses used by processes do not refer to the physical location. Rather the address is a virtual address, and the processor translates it by some means to the physical address.
Eg, if a process accesses memory at 0xfe12a201, the physical memory accessed might be 0x0000c445. The former address is a 'virtual' address, the latter is physical.
Typically:
Processors work with memory in discrete chunks called pages. A page might be 4KB of memory (eg on intel), or some other value. Each page has a number, a frame number (PFN), that identifies it. The part of the processor that deals with handling virtual memory is the Memory Management Unit (MMU). The MMU and operating system together maintain a set of tables that describe which pages correspond to which virtual memory addresses. These tables are known as "Page Tables" or "PT", each entry in a page table is a "Page Table Entry" or "PTE". A page table is usually held within one or more set of physical pages. Each process has it's own set of page tables. The MMU interprets a part of the virtual address as an index:offset into the page tables. By looking up the PTE at offset x in the PG indexed by y, the MMU can determine which physical memory address corresponds to a virtual address (and more besides).
eg:
process accesses memory at 0xfe12a201.
MMU interprets 0xfe12a as the index, and retrieves the 0xfe entry (PTE) in the page table, which tells it which PFN the virtual address refers to. it then uses 0x201 as the offset into that page and fetches/operates on the memory located there.
ie:
- virtual address -> split into index and offset.
- index gives you the PTE.
- the PTE holds the frame number of the physical page (and some other stuff)
- the offset is the location within the frame
So everytime, (well nearly everytime), a process accesses memory, the MMU translates the virtual address in the above way. To speed things the MMU maintains a cache of translations in a unit known as the Translation Lookaside Buffer (TLB), which holds recent translations. If the MMU finds a translation there, it doesn't need to do the full lookup process.
so where does the operating system, or rather it's VMM, come in? well, a MMU might find that when it goes to look up an index, that no valid PT or PTE exists. This might indicate the process is trying to access memory that it hasnt been allocated, the MMU would then raise a fault and switch control to the operating systems VMM code, which would probably decide to end the process with a memory access violation, eg SEGV under Unix, and perhaps dump the processes memory to a file to aid debugging. (a core dump.)
also, the PTE holds more than just the frame number. There are various extra bits which the MMU and operating system can use to indicate the status of a page.
Eg, one bit may indicate whether the page is valid or not. an OS'es VMM could use this to make sure that the MMU faults control to the VMM next time the page is accessed, perhaps to allow the VMM to read the page from disk into memory (ie swap).
Other bits may indicate permission. Eg whether a page may be read or written to. This can facilate shared libraries by allowing an OS to map the same physical pages into the page tables of several different processes. Also facilites copy on write, for optimising fork().
The cpu's MMU may maintain an 'accessed' bit and a 'written' bit to indicate whether a page has been accessed/written to since the last time the bit was cleared, so that the operating system can do bookkeeping and make informed decisions about memory activity.
etc.. etc..
The VMM's job beyond interacting closely with the MMU is to juggle which pages are kept in memory and which are swapped out to disk. perhaps if the OS does paged buffering, the VMM may also need to decide which buffer pages need to be written to disk (or read in pages to buffers). there are many ways it could do this, eg by maintaining lists of how and how often pages are used and make decisions about what to write out/read in based on that.
it is in these intricate details that the various 2.4 VMMs differ.
NB: details above are very architecture specific. different processors will have different page table layouts, different PTE status bits, etc.. eg on intel the virtual address is actually
the directory index is an index to a directory of page table numbers, which saves on the amount of memory you need to hold a page table. the upshot being that the fine details of how paging works are processor specific.
More NB's:
page tables are process specific, switching between processes usually requires loading in the (set of) page tables of the new process. it also requires clearing out/invalidating all the existing TLB entries. this all takes time.
Intel have an extension to their paged addressing, PAE, which allows for 36 bit physical addresses. I'm not sure, but i think it does this by splitting the directory index into 2 indexes, and increasing the PTE size to 36bits. (uses 64bits of memory though.)
finally... there is plenty of reference materical on the web, so research for yourself cause i'm probably wrong in a lot of places. ah well..:)
Slashdot Mirror
javierco is right, and you're full of the proverbial bull's faeces.
little/big endian makes no difference to performance. if anything, for networking little endian are at a disadvantage to big-endian machines as the likes of htons(),ntohs() are not no-ops.
similarly, big-endian machines might have to byte-swap little-endian data formats. (eg ext2/3, etc.) and PCI is little-endian, so data to/from PCI cpu has to be byte-swapped, but that's arbitrary. there is no inherent performance advantage to either byte order.
also, some CPUs can use either byte order, eg MIPS.
that said, nearly everything, is little-endian, simply because of the prevalence of i386.
No,
if you read the recent thread on l-k, it's because in private Linus has been talking for quite a while to the bitkeeper people about what he wanted from bitkeeper before he'd use it, and the bitkeeper people have gone and implemented most of it, so Linus agreed to use it for a while.
yep..
US: T1 1.544Mb/s
Europe (and most of rest of world apart from Japan): E1 2Mb/s
T2: 6.312Mbps
E2: 8.448 Mbs
T3: 44.736Mbs
E3: 34.368Mbs
Japan uses something very similar to the US Tx system, iirc.
pah...
/root]# uptime
/root]# rpm -q redhat-release
/root]# uname -r
[root@adelphi
8:46am up 253 days, 5:55, 10 users, load average: 0.02, 0.09, 0.08
[root@adelphi
redhat-release-6.1-1
[root@adelphi
2.2.14
now that figure of 253 is not the real uptime. cause 2.2 i386 uptime rolls over after 498 days. so the real uptime is 751 days - 2 years 39 days. this machine was powered up before i was even working here, and i'm the 2nd longest serving admin.
:)
underscore is an illegal char in hostnames. lot of things wont resolve it, eg squid proxies for one.
what absolute balls.
MAC addresses are link local. they do not propogate to other links. the only MAC address they will see is the one of your DSL interface.
that may a supporting reason, but actually the primary reason is due to concerns about EMR interfering with the aircraft systems.
/hear/ phones negotiating with base stations in their headsets. (hold an active mobile near a radio or monitor sometime).
eg, mobile phones: before they cracked down on their use, the pilots often would
so in addition to banning mobile phones (use of or switched on) on flights, they've also cracked down on use of any electronic gear to be safe.
well, let's agree to differ about the right to whine then.
:)
/agree/ that stuff like the above would not be something your normal joe bloggs user would like to have to do, which is why companies like redhat develop things like bug-buddy. i dont see why this should be such a contraversial point either, why it should produce accusations of 'geek snootiness'. Those who can use the tools, should use them, those who cant need to have GUI tools written for them. the latter class will most likely be written by the distro suppliers as it is in their interest to make the product they are /selling/ as easy to use as possible.
/part/ of open-source even if you are not a developer.
:) ).
"If you ask me, YOU are a lot of the problem with Linux (off subject). Snooty GEEKS that can't stand to hear that Wind Blows might still have something up on Linux"
well, whether i'm a snooty geek or not is irrelevant, precisely because this is open-source and so anyone, be they non-snooty geeks or support companies who exist to give non-snooty support to users, have access to the code and can fully support you. as for caring about 'wind blows', i dont.
now, for non-snooty help: if you have an application that keeps crashing and you wish to investigate you can:
- run it under/attach to it with strace and see whether it crashes at the same point each time. ie:
strace -f programme
or
strace -f -p pid
- run under ltrace to trace library calls. often (especially with GUI software) the problem is with libraries and not the actual application.
syntax is similar to strace.
- run the application under gdb, or run gdb on the core file and get a 'backtrace' which is a 'history' of the calls immediately 'preceding' the crash. if you have a core file:
gdb -c corefile programme
you get a prompt. type in 'bt', a bunch of information should be printed out, copy this to an email and send it to the developer. to run the application from gdb
gdb programme arguments
you get a prompt. type 'run' to run the application. when it crashes you will be returned to the gdb prompt, type 'bt' to print the backtrace. again, mail that to the developer.
to quit from gdb: 'q'
and that's it..
NB: some distro's might set a system limit on corefiles, eg to 0 to prevent them altogether. use 'ulimit -c 100000000000' to remove the limit.
now, i'd
With respect to your post, you didnt state that you had actually done anything about the problem. it's only now that you say you tried KDE's crash app. Open-Source is a double-edged sword, you get quality code for free, but in return when you encounter a problem you should at least try to do something to allow the developers of that application to fix the problem.
if every open-source user had the attitude of "uhhh.. it crashed.. linux still has a long way to go" and left it at that well then we might as well give up now. sorry, but as an open-source user you are almost obligated to do something about problems, ie at least report them. you are a
(and before you call me snooty again, if you are a paying customer of a distribution vendor, then the obligation is on the distribution vendor. you have chosen for a business relationship, go whine at your vendor.
nice to see the moderators doing their best to make sure slashdot discussions are as bland as possible..
anyway, in answer to your comment:
"my internet access doesnt work"
i'd say: "did it crash? ok, run gdb on it, etc.. etc.."
redhat say: "just use our spiffy gnome setup tool"
that's why the likes of RedHat exist - precisely to make sure that normal users do not have to deal with insular zealots and do not have to get involved with debuggers. they get a pointy clicky tool that RedHat (or whoever) have made as fool proof as possible.
normal users -> catered to by distros
'zealots' -> catered to by the other zealots and developers
both groups can have they what want..
this guy /knows/ pppd is crashing on him, he at least should have enough gumption to be able to subscribe to a list or email a developer directly and ask for help (and hence maybe be asked "can you do the following .... gdb ... bt ..... ?")
linux on the desktop. i dont really care, neither do the people who write things like pppd daemons or kernel code. this is the domain of the companies who put together distributions.
(and i agree with the other poster that 'talkback' or 'bug-buddy' like stuff for system software would be useful.)
yep it is. :)
however, there is another machine running 2.4 that does get reasonably loaded at times, eg it often has context switch / second rates in the many thousands/sec for sustained periods of time. (highest seen this month so far 7873.12 c'switches/sec). it's a dual cpu 1GB compaq server. (the other was a uni proc, 128mb compaq server), and it's been up for 27 days so far with 2.4.9 - only 27 cause of a reboot due to an nfs problem (which was probably due to a mistake in firewalling).
2.4 does indeed have problems with corner cases. however, this is probably more of a problem for desktops than for servers that have admins paid to watch and tune them.
pppd keeps crashing? shame on those awful developers who gave you this piece of crashing software for free with source.
/do/ something about the problem! you could at the very /least/ report the problem!! otherwise dont whine.
have you even made any attempt to try find out why it crashes? eg, run gdb on the core file and type in "bt" to get a backtrace, and send the output to the developers?
even enquired on any mailling lists about your problem? (and hence maybe come into contact with people who could have told you "get a backtrace and here's how you do it" if you didnt know it yourself).
there's nothing worse than people whining about problems with GPl or other open-source software. you can
[root@ns root]# uptime
10:00am up 246 days, 23:57, 1 user, load average: 0.00, 0.00, 0.00
[root@ns root]# uname -r
2.4.5-pre1
this was the first critical server i ever installed a 2.4 kernel on. (it does dns).
checkout:
directory_administrator which is a GNOME LDAP user admin tool (slick enough for use by a frontline helpdesk).
there are other LDAP GUI's, KDE has one. search freshmeat.
gq a general purpose LDAP GUI tool. quite slick, comes with RH7.x.
Also, note that with RH7, the 'passwd' tool uses pam and will hence automatically work with LDAP authentication. (presuming your LDAP server is configured correctly for write access).
finally, you'll probaby want to develop your own scripts with template LDIF's for things like useradd, or find someone who's already done so. (i noticed there's a post on this thread providing a link to exactly that.) Note that for scripting, PADL's migration scripts are very informative. These are included with the OpenLDAP distribution.
some databases (oracle and postgresql are 2 i know of) support BLOB data types. BLOB = Binary Large OBject, ie a big blob of data. you'd store your file contents in that.
de4x5 is DEC's own driver for the DE4x5, DE500-XX cards and the DE-2104x-XX and DE-2114x-XX chips. in addition any 3rd party card that use a DEC (or clone) 21{0,1}4x chipset and uses DEC's SROM format are supported.
(read the top of drivers/net/de4x5.c).
tulip is Donald Beckers driver. It is the newer of the 2, and supports more types of tulip cards/chipsets/srom formats than the Digital de4x5 driver does. It also was the more higher-performance and more 'linux' driver. however, the addition of support for every weird type of DE21x4x clone card has cruftified the tulip driver ever so slightly.
for 2.5, i believe they plan to rip tulip apart.
actually:
/extremely/ stable.
/proc interfaces, etc..). Note that the most significant determinant of the stability of the ABI is /not/ the kernel, rather it is libc and libc++. (ie glibc for most linux systems.) If you have the right libraries you can still run 5 year old a.out binaries on linux 2.4.
the Linux API is
the Linux ABI is also very stable. the only thing that isn't guaranteed stable is extremely low-level linux-specific interfaces. (Eg firewalling, routing, network setup,
the internal kernel API is not stable. and linus likes it that way.
xterms are about $400 to $600 new - not including monitor.
they're not cheap capital wise, the benefit is fire and forget, zero maintenance, less admins needed to tinker and care for workstations. (it breaks, just throw another in it's place).
--paulj
"tainted" in this context means the kernel has had code loaded into it that the kernel developers can not support.
Eg, you load a vendor binary-only module (eg NVidia DRI module), the kernel developers can not debug any problems a user may have with that kernel as they do not have the source. Only NVidia can debug the problem fully.
It's not a matter of principles, it's a matter of practicality.
flamer...
/will/ load non-GPL compat modules, but it will mark the kernel as tainted.
insmod
read the man page for insmod.
i do not support violence..
but, the violence in Northern Ireland over the last 25 years was as a direct result of Britains policies in Northern Ireland since the partitioning of Ireland in 1922.
There was institutional discrimination against the catholic community in Northern Ireland, and the govt in England turned a complete blind eye to it. In the 1960s unemployment amongst catholics was at 30 to 40%, while only at 10ish% for protestants. The Police force, business, the institutions of regional government were all dominated by the Protestant/Unionist community in Northern Ireland, and for the most part they used their power to oppress the catholic/nationalist minority. All with a blind eye turned by the UK government in England, or even it's approval.
So some of this oppressed minority people turned to violence. not a solution i would condone, but neither can you condone what went on in Northern Ireland post-WWII in the name of the United Kingdom.
Note that there also were many out of this community who tried peaceful means to change their plight. They'd hold peaceful civil rights marches. And they'd be met and beaten by the RUC, or on one occasion mown down by British paratroopers. (Bloody Sunday Jan 30 1972, Derry, 13 civilians shot dead by the Para's).
NI was a mess, a brutal mess and it produced some brutal people who committed some terrible acts. But the cause of it all was british actions and inaction.
there does seem to be light at the end tunnel now though. they've gotten it down to politicians throwing words at each other, rather than bombs.
anyway...
ehmmm... try this:
/usr/src/redhat/RPMS/i386/kernel\t\t\n
untar the kernel source
make config
make rpm
rpm -i
aye... stupid.
yes linux supports metrics.
however, this method will only work for physical link failures that are detected. (and i dont think linux does much even if it does detect a link failure).
needless to say the vast majority of network failures tend not to be detected link failures.
my suggestion would be to use OSPF for link state and route failure detection and failover.
I'll have a stab at this one... not all the details might be correct, but it should be close enough to get the idea..
:)
VM is virtual memory. really in this context it should be: VMM, ie Virtual Memory Management.
VM refers to the fact that on modern processors memory addresses used by processes do not refer to the physical location. Rather the address is a virtual address, and the processor translates it by some means to the physical address.
Eg, if a process accesses memory at 0xfe12a201, the physical memory accessed might be 0x0000c445. The former address is a 'virtual' address, the latter is physical.
Typically:
Processors work with memory in discrete chunks called pages. A page might be 4KB of memory (eg on intel), or some other value. Each page has a number, a frame number (PFN), that identifies it. The part of the processor that deals with handling virtual memory is the Memory Management Unit (MMU). The MMU and operating system together maintain a set of tables that describe which pages correspond to which virtual memory addresses. These tables are known as "Page Tables" or "PT", each entry in a page table is a "Page Table Entry" or "PTE". A page table is usually held within one or more set of physical pages. Each process has it's own set of page tables. The MMU interprets a part of the virtual address as an index:offset into the page tables. By looking up the PTE at offset x in the PG indexed by y, the MMU can determine which physical memory address corresponds to a virtual address (and more besides).
eg:
process accesses memory at 0xfe12a201.
MMU interprets 0xfe12a as the index, and retrieves the 0xfe entry (PTE) in the page table, which tells it which PFN the virtual address refers to. it then uses 0x201 as the offset into that page and fetches/operates on the memory located there.
ie:
- virtual address -> split into index and offset.
- index gives you the PTE.
- the PTE holds the frame number of the physical page (and some other stuff)
- the offset is the location within the frame
So everytime, (well nearly everytime), a process accesses memory, the MMU translates the virtual address in the above way. To speed things the MMU maintains a cache of translations in a unit known as the Translation Lookaside Buffer (TLB), which holds recent translations. If the MMU finds a translation there, it doesn't need to do the full lookup process.
so where does the operating system, or rather it's VMM, come in? well, a MMU might find that when it goes to look up an index, that no valid PT or PTE exists. This might indicate the process is trying to access memory that it hasnt been allocated, the MMU would then raise a fault and switch control to the operating systems VMM code, which would probably decide to end the process with a memory access violation, eg SEGV under Unix, and perhaps dump the processes memory to a file to aid debugging. (a core dump.)
also, the PTE holds more than just the frame number. There are various extra bits which the MMU and operating system can use to indicate the status of a page.
Eg, one bit may indicate whether the page is valid or not. an OS'es VMM could use this to make sure that the MMU faults control to the VMM next time the page is accessed, perhaps to allow the VMM to read the page from disk into memory (ie swap).
Other bits may indicate permission. Eg whether a page may be read or written to. This can facilate shared libraries by allowing an OS to map the same physical pages into the page tables of several different processes. Also facilites copy on write, for optimising fork().
The cpu's MMU may maintain an 'accessed' bit and a 'written' bit to indicate whether a page has been accessed/written to since the last time the bit was cleared, so that the operating system can do bookkeeping and make informed decisions about memory activity.
etc.. etc..
The VMM's job beyond interacting closely with the MMU is to juggle which pages are kept in memory and which are swapped out to disk. perhaps if the OS does paged buffering, the VMM may also need to decide which buffer pages need to be written to disk (or read in pages to buffers). there are many ways it could do this, eg by maintaining lists of how and how often pages are used and make decisions about what to write out/read in based on that.
it is in these intricate details that the various 2.4 VMMs differ.
NB: details above are very architecture specific. different processors will have different page table layouts, different PTE status bits, etc.. eg on intel the virtual address is actually
directory index : page table index: offset
11 bits : 9 bits : 12 bits
the directory index is an index to a directory of page table numbers, which saves on the amount of memory you need to hold a page table. the upshot being that the fine details of how paging works are processor specific.
More NB's:
page tables are process specific, switching between processes usually requires loading in the (set of) page tables of the new process. it also requires clearing out/invalidating all the existing TLB entries. this all takes time.
Intel have an extension to their paged addressing, PAE, which allows for 36 bit physical addresses. I'm not sure, but i think it does this by splitting the directory index into 2 indexes, and increasing the PTE size to 36bits. (uses 64bits of memory though.)
finally... there is plenty of reference materical on the web, so research for yourself cause i'm probably wrong in a lot of places. ah well..
linux 2.4 supports up to 64GB on i386 using intel's PAE extensions which allow for 64GB of physical memory on i386.
per process memory is still restricted to 32 bits addressable though, ie 4GB.