Re: Swap configuration for 2GB phys RAM
Daniel Lang wrote: We've just bought a Dell PowerEdge 2650 with Dual Xeons and 2 GB of RAM. I thought I would just install it the usual way, which would include reserving 4 GB swap. Now I'm not sure if I would run into problems, as this would match the entire address space. There has been a recent thread about someone who ran into possible problems because of that. The problem in that case had to do with a page fault in a particular cirumstance when running a UFS in a vn on a UFS. It's a problem with the vn device. My suggested workaround was to modify the daily cron script, or to move the vn devices into subdirectories. He was also hitting near the limit of the KVA space, but was nbot going over because he never needed to swapm with the load he had. Probably should have posted the results back to the list in more detail... I wonder what I could do to prevent any problems. Is is advisable to increase the kernel address space (KVA is this?) in my custom kernel? Not for 2G (IMO), unless you tune stuff up (mbufs, mbuf clusters, etc.)... *way* up. I've found in the handbook (could also be the FAQ) a paragraph that stated, if the hardware (MMU) would support it, FreeBSD could address 8 TB of (I guess virtual) memory. The poweredge can even be equipped with 6 GB RAM, which is already past the 4GB limit of a standard 32bit address space. So I wonder if it would be possible to just use the memory as usual? No. The 8TB limit is elsewhere. The MMU on the 32 bit machine limits you to 4G total KVA + UVA. The 6G in the Dell is bank selected (PAE based). Peter Wemm was talking about hacking it in, but at that point, with what you end up paying, you might as well buy an IA64 instead, and not eat the PAE overhead (IMO). I don't know of the Xeon's have a different MMU which enables to address more than 4 GB, but from my guts I would doubt it. It seems that some people have machines like this in production. So any hints or advice would be appreciated. See the output of dmesg | more; if the CPU line has PAE as one of the attributes of the CPU, the CPU itself supports the idea of bank selecting memory above 4G. If you actually modified the VM system to use this (or convinced Peter to), then your limit would be KVA + UVA + PAE_window = 4G, so you would actually lose some overall address space from somewhere to pay for the ability to access the extra RAM, and you could only DMA into it if you passed your hardware 64 bit addresses, and the hardware supported it. See The very long PAE discussions that have occurred on these lists (e.g. Linux supports it, it makes them slower, but we should support it too, because Linux does, etc.). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Swap configuration for 2GB phys RAM
Thus spake Daniel Lang [EMAIL PROTECTED]: I've found in the handbook (could also be the FAQ) a paragraph that stated, if the hardware (MMU) would support it, FreeBSD could address 8 TB of (I guess virtual) memory. The poweredge can even be equipped with 6 GB RAM, which is already past the 4GB limit of a standard 32bit address space. So I wonder if it would be possible to just use the memory as usual? No 32-bit architecture can address 8 TB of virtual memory with a flat address space. A single process can only address 2^32 bytes with 32-bit pointers. Furthermore, the kernel is mapped into every process' address space, reducing the room available. However, it is possible to have more than 4 GB of physical memory, and split it between several processes. On recent i386s, you can use up to 64 MB using bank switching, which is a bad idea that has been reinvented at least a dozen times. The comment that you read should probably say, ``If the hardware supported it a long time ago, someone would have revamped the FreeBSD VM to make use of the support by now.'' Nobody has bothered yet, to my knowledge, but rumor has it that Peter Wemm is working on it, and a few months ago I think David Greenman mentioned possibly doing the same. But a far better solution is to get a 64-bit processor. They can use more than 4 GB of physical memory The Right Way, and an individual virtual address space can be larger than 4 GB. Unfortunately, lots of third-party software doesn't work on 64-bit architectures. I've been struggling for a while to get a Java VM to work on ia64. That's because I need to run some Java programs that, like most Java programs, need to address more than 4 GB of RAM. Sigh. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
new keycodes and extra keyboard buttons
Is there any work being done to support the extra keyboard buttons on modern keyboards ? I have integrated support for the Logitech cordless iTouch keyboard successfully, so I would like to know if I could contribute to any existing work or if I should continue with my own efforts. Yorick Hardy. - This message was sent using MetroWEB's WebMail service. http://www.metroweb.co.za/ - full access at only R49.95 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding readdir entries to the name cache ...
On Thu, 4 Jul 2002, Terry Lambert wrote: [major snippage, much useful to think about here ...] However, ls seems to call lstat in the same order that the files are in the directory, and a normal clock approach to directories would yield exactly the same result. Further, in the cases that the user did not want a -l, we would avoid adding many potentially useless names to the name cache and reducing its performance. This is because the sort occurs first. An unsorted ls (which is available -- see the man page) doesn't have this issue. I don't want to start a flame war, but a truss of ls -l shows the following: getdirentries(0x5,0x809d000,0x1000,0x80990b4)= 4096 (0x1000) lstat(.gnome,0x809c248)= 0 (0x0) lstat(.mc,0x809c348) = 0 (0x0) lstat(.xinitrc,0x809c44c) = 0 (0x0) lstat(750B.pdf,0x809c54c) = 0 (0x0) lstat(Mail,0x809c648) = 0 (0x0) lstat(nsmail,0x809c748)= 0 (0x0) lstat(.cshrc,0x809c848)= 0 (0x0) lstat(.ssh,0x809c948) = 0 (0x0) lstat(.gnome_private,0x809ca50)= 0 (0x0) lstat(.xchat,0x809cb48)= 0 (0x0) lstat(.exmh,0x809cc48) = 0 (0x0) lstat(.ICEauthority,0x809cd50) = 0 (0x0) lstat(.netrc,0x809ce48)= 0 (0x0) This is the same order that 'ls -fal' produced. This suggests that the ls is doing an unsorted lookup of the info, and then sorting. That is the way I would have done it as well. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding readdir entries to the name cache ...
On Thu, 4 Jul 2002, Terry Lambert wrote: Richard Sharpe wrote: Note that you can get another 8-12% by making negative cache entries, since DOS/Windows clients tend to search the full path each time, even though they have already received a successful response in the past (i.e. there is no client caching for this information, because there is no distributed coherency protocol that would permit server invalidation of the cache). Unmodified, SVR4 DNLC can not support negative cache entries (there need to be two line changes). Hmmm, I think that the major part of the problem there was that, for what ever reason, Barry Feigenbaum of IBM, declined to add a Change Working Directory or Set Working Diretory command to the SMB protocol. Thus, at least for the SMB protocol, and maybe generally, Windows clients must always send the full pathname for every file they want, unless it happens to be at the root of the share. Perhaps I am wrong about that. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding readdir entries to the name cache ...
At 6:29 AM +0930 7/6/02, Richard Sharpe wrote: Hmmm, I think that the major part of the problem there was that, for what ever reason, Barry Feigenbaum of IBM, declined to add a Change Working Directory or Set Working Diretory command to the SMB protocol. Thus, at least for the SMB protocol, and maybe generally, Windows clients must always send the full pathname for every file they want, unless it happens to be at the root of the share. Could the unix process for samba fake that? Keep track of the most recently used directory, and when a new request comes in split it into directory plus filename, and if the directory is the same as the previous one, then just access the filename. If the directory is different, try to do a chdir() to the new directory, and if that succeeds then save that as the previous directory. Or is that more trouble than it's worth? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Case independent file name searched (was Re: Adding readdir entriesto the name cache ...)
On Thu, 4 Jul 2002, Terry Lambert wrote: Richard Sharpe wrote: [1] Samba, because it has to support the Windows case insensitive file system, must do some pretty ugly things :-) When a client asks that a file be opened, for example, Samba tries with exactly the case that was presented. If that fails, it must do a readdir scan of the directory so it can do a case-insensitive match. So, even negative caching does not buy us much in the the case of Samba. What would help is a case insensitive filesystem. It is useful to be able to do case sensitive on storage, case insensitive on lookup on a per process basis. The easiest is if you wire this in as a flag on the proc itself. The normal way this is done is a flag to sfork, but... it should also be possible to have the proc open itself in procfs, and then ioctl() down a flag setting for this. I have come to the conslusion that Terry is right. Having watched a cygwin-based build of a package, the behavio[u]r is just too ugly. When an include file is looked for, it causes Samba to do readdir scans for every directory in the -I chain that the include file is not in until it is found. If we could eliminate all those readdir scans performance would improve dramatically. Fundamentally, what I want to support is both UNIX clients (say, via NFS etc) and Windows clients to be able to share files in the same directory. Samba already does case-preserving file name creation, and indeed, the problem does not go away even if Samba always case-folds all names to lower case, because a UNIX-user or -client might still create two files that differ only by the case of one or more characters in their names. This means that Terry is right when he says I need an IOCTL. Basically, normal users get the normal case sensitive file system, while Windows clients, via an IOCTL which says, give ME case-independed lookups, get a slightly different file system. To support that, however, I need to change the name cache hash function to be case-insensitive (there's more--see below). This means that name cache hash chains could get longer. In the worst case, if a file system contains large numbers of files with long names, all using the same characters that only differ by case of indivual characters, the hash chain becomes a linear search. However, UNIX file systems generally don't get like that. I imagine that the hash chains will grow to no more that twice their current size, but will probably grow by a factor close to one. Another problem is the extra complexity required in cache_lookup. When we want cache-insensitive lookups, we have to do extra work, even if we find a match in the cache. The problem is with files that differ by only the case of one or more characters. When this occurs, my view is that we should return the file with the longest string of exactly matching characters, however, we might allow the sys admin to set policy, at the expense of complicating things. When we search a hash chain, if we get an exact match, we are done, but if we don't get an exact match, we still have to do a readdir scan to find a better match, and to ensure that we return consistent results. Similarly, when we do a readdir scan, if we get an exact match, we are done, but if we don't, we need to keep going. Another aspect that needs consideration is the effect on negative caching. Getting a negative result on the exact name match is no good anylonger, since there may be a case-insensitive match in the directory. This seems to make negative cache entries useless for case-insensitive matching. Finally, I think that persuing this subject some more is very important from the point of view of constructing high-performance CIFS servers, based on Samba or other software, so I would appreciate comments. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding readdir entries to the name cache ...
On Fri, 5 Jul 2002, Garance A Drosihn wrote: At 6:29 AM +0930 7/6/02, Richard Sharpe wrote: Hmmm, I think that the major part of the problem there was that, for what ever reason, Barry Feigenbaum of IBM, declined to add a Change Working Directory or Set Working Diretory command to the SMB protocol. Thus, at least for the SMB protocol, and maybe generally, Windows clients must always send the full pathname for every file they want, unless it happens to be at the root of the share. Could the unix process for samba fake that? Keep track of the most recently used directory, and when a new request comes in split it into directory plus filename, and if the directory is the same as the previous one, then just access the filename. If the directory is different, try to do a chdir() to the new directory, and if that succeeds then save that as the previous directory. Yes it can do that, and should do that. I will have to check what Samba does. I know I proposed adding a path cache to smbclient/smbtar so that it could avoid repeatedly, and even a cache of one path could make a big difference. Or is that more trouble than it's worth? No, I think it is worth a lot. I suspect Samba already does that. There is just so much code to look at. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding readdir entries to the name cache ...
Richard Sharpe wrote: On Thu, 4 Jul 2002, Terry Lambert wrote: [major snippage, much useful to think about here ...] However, ls seems to call lstat in the same order that the files are in the directory, and a normal clock approach to directories would yield exactly the same result. Further, in the cases that the user did not want a -l, we would avoid adding many potentially useless names to the name cache and reducing its performance. This is because the sort occurs first. An unsorted ls (which is available -- see the man page) doesn't have this issue. I don't want to start a flame war, but a truss of ls -l shows the following: [ ... ] This suggests that the ls is doing an unsorted lookup of the info, and then sorting. That is the way I would have done it as well. My bad; I had assumed that what he said he was observing was actually what he was observing. It may be that he's installed an ls replacement or something, or it could just be an artifact of the directory he's looking in. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Swap configuration for 2GB phys RAM
Hi, thanks David and Terry. Ok, I guess it's not a problem yet to have 2 GB RAM and 4 GB swap. The machine did install quite smoothly. I'm having some trouble with the serial ports, though. I will post this to -questions... Best regards, Daniel -- IRCnet: Mr-Spock- Der Zweite Platz ist Dreck - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 25735 * http://www.leo.org/~dl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
How does swap work address spacewise?
If RAM + swap can be more than 4GB, how does FreeBSD address swap on a 32-bit machine? Does the kernel internally use a wider address space with some kind of translation to 32-bit space for programs and hardware that can't handle 64-bit addresses or does it not map swap into the address space at all, instead using it as a kind of offline storage for pages not in use? Does the Alpha port handle swap the same way? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How does swap work address spacewise?
On Fri, Jul 05, 2002 at 05:58:15PM -0700, Darren Pilgrim wrote: If RAM + swap can be more than 4GB, how does FreeBSD address swap on a 32-bit machine? Does the kernel internally use a wider address space The same way it does on every partitition: using block numbers. That way you can address 1TByte. And you can have more than a single swap partition. In reality managementstructures which have to be in kernel addressspace is limiting swap before. with some kind of translation to 32-bit space for programs and hardware Don't mix address space with ram and swap. While you can have more than 4G swap you can't have more than 4G addressspace. But you can have multiple different 4G addressspaces - each process with its own. that can't handle 64-bit addresses or does it not map swap into the swap is logicaly mapped into address space, but not more than 4G in a single one. address space at all, instead using it as a kind of offline storage for pages not in use? Does the Alpha port handle swap the same way? Yes - I see no reason to do it different. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ctrl alt del behaviour
Hello, No flames please, before I am posting this message I did: -read all kinds of faq and docs on www.freebsd.org -searched a lot the web -posted this question to freebsd questions -searched more and more -looked up for help in irc #freebsd channels -searched more -posted again to freebsd questions -and searched more. And if there is a place I can get the answer, the place is here... The issue about ctrl+alt+del is that I need to change the default behaviour that is reboot, to halt the system. The best I could find was to change the keymap on key 83 (if I am not mistaking) to 'pdwn' or 'halt' (it was previously on 'boot'). After rebooting to the changes take effect (I do not know if there is a way to reload the keymap withou restarting the system), I try ctrl+alt+del and then it runs the proper halt/shutdown script, but when it was supposed to stop (halt) for the user press the power button, it does automaticaly reboot. Is there a way to just halt (and stay halted) using ctrl+alt+del? TIA Paulo __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How does swap work address spacewise?
Darren Pilgrim wrote: If RAM + swap can be more than 4GB, how does FreeBSD address swap on a 32-bit machine? Does the kernel internally use a wider address space with some kind of translation to 32-bit space for programs and hardware that can't handle 64-bit addresses or does it not map swap into the address space at all, instead using it as a kind of offline storage for pages not in use? Does the Alpha port handle swap the same way? KVA + UVA = 4G KVA is per system... but UVA is per process. Therefore you can have as much as you want, so long as it's per process, and you only run processes one at a time (which is what kernels do ;^)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
