Re: Replacement for grep(1) (part 2)
Doug Rabson wrote: > Overcommit can be used for many reasons. I use it to reserve a large > linear address space to mmap alpha i/o spaces to which allows an efficient > implementation of inx/outx in user mode: > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 0 43655 43652 7 2 0 12616584 12456 select S ?? 1036:41.62 > /usr/X11R6/bin/X -auth /usr/X11R6/lib/X11/xdm/authdir/A:0-w43652 > > The X server is using 12G of address space.. This is not an argument for malloc() to overcommit by default, it is an argument for there to be a way of allocating address space with no swap reserved *when you specifically ask for it*. Of course I would not disagree with this. Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Doug Rabson <[EMAIL PROTECTED]> wrote: > Overcommit can be used for many reasons. I use it to reserve a large > linear address space to mmap alpha i/o spaces to which allows an efficient > implementation of inx/outx in user mode: > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 0 43655 43652 7 2 0 12616584 12456 select S ?? 1036:41.62 >/usr/X11R6/bin/X -auth /usr/X11R6/lib/X11/xdm/authdir/A:0-w43652 > > The X server is using 12G of address space.. This is not an argument for malloc() to overcommit by default, it is an argument for there to be a way of allocating address space with no swap reserved *when you specifically ask for it*. Of course I would not disagree with this. Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Alfred Perlstein wrote: > You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. vfork() > you also have to consider a program wishing to make sparse use > of its address space, without overcommit it becomes impossible. So Don't Do That Then. Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" wrote: > > I can add it to the list of reasons I don't use it then I guess ;-). > > Whatever. The operating system you use also does it. How terribly tedious. Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Alfred Perlstein <[EMAIL PROTECTED]> wrote: > You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. vfork() > you also have to consider a program wishing to make sparse use > of its address space, without overcommit it becomes impossible. So Don't Do That Then. Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > > I can add it to the list of reasons I don't use it then I guess ;-). > > Whatever. The operating system you use also does it. How terribly tedious. Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Sheldon Hearn wrote: > You're rehashing stuff that's been discussed to death. Please look at > the mailing list archives for this mailing list. I'd love to, could you please be more specific? I can't find anything relevant searching for 'malloc' or 'overcommit'. > If you're not prepared to do that, the long and the short of it is that > FreeBSD _does_ overcommit, we like it that way and neither of these two > facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" wrote: > That's *not* abomination. How about pre-allocating over 100 Mb for X > Free, for instance? What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. > Basically, if you don't have enough memory, you just don't have enough > memory. Yes, and the application should be told this via the standard documented interface for doing so, i.e. returning NULL from malloc(). > What FreeBSD does *reduces* the need for memory. If FreeBSD *did > not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Sheldon Hearn <[EMAIL PROTECTED]> wrote: > You're rehashing stuff that's been discussed to death. Please look at > the mailing list archives for this mailing list. I'd love to, could you please be more specific? I can't find anything relevant searching for 'malloc' or 'overcommit'. > If you're not prepared to do that, the long and the short of it is that > FreeBSD _does_ overcommit, we like it that way and neither of these two > facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > That's *not* abomination. How about pre-allocating over 100 Mb for X > Free, for instance? What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. > Basically, if you don't have enough memory, you just don't have enough > memory. Yes, and the application should be told this via the standard documented interface for doing so, i.e. returning NULL from malloc(). > What FreeBSD does *reduces* the need for memory. If FreeBSD *did > not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" wrote: > > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > > > of memory error. > > > > Why is that? > > Because memory (as in *real* memory, either RAM or swap) is > allocated on-demand. So you can allocate any amount of virtual > memory that the system can possibly provide you, even though you'll > run out of memory much earlier, because other resources are also > consuming it. Yuck. That's a complete abomination. What's the point of it? It's turning an out-of-memory situation from an easily-detected recoverable temporary resource shortage which can be worked-around or waited out, into an unrecoverable fatal error. Do a significant number of programs really request memory which they then proceed not to use? > > What happens if the process hits its resource limits? > > If the system runs out of memory, the biggest process is killed. It > might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > > > of memory error. > > > > Why is that? > > Because memory (as in *real* memory, either RAM or swap) is > allocated on-demand. So you can allocate any amount of virtual > memory that the system can possibly provide you, even though you'll > run out of memory much earlier, because other resources are also > consuming it. Yuck. That's a complete abomination. What's the point of it? It's turning an out-of-memory situation from an easily-detected recoverable temporary resource shortage which can be worked-around or waited out, into an unrecoverable fatal error. Do a significant number of programs really request memory which they then proceed not to use? > > What happens if the process hits its resource limits? > > If the system runs out of memory, the biggest process is killed. It > might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" wrote: > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > of memory error. Why is that? What happens if the process hits its resource limits? Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > of memory error. Why is that? What happens if the process hits its resource limits? Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
