Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Noriyuki Soda
> On Thu, 15 Jul 1999 11:09:01 -0700 (PDT), Matthew Dillon said: > Umm... how are you getting the reserved numbers? "pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page: :-s Print summary information about total swap : space

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Noriyuki Soda
> On Thu, 15 Jul 1999, Daniel C. Sobral wrote: >> Uh... like any modern unix, Solaris overcommits. > On Thu, 15 Jul 1999 08:46:36 -0700 (PDT), "Eduardo E. Horvath" said: > Where do you guys get this misinformation? : > Note the `19464k reserved'; that space has been reserve

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Noriyuki Soda
> On Thu, 15 Jul 1999 11:09:01 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > Umm... how are you getting the reserved numbers? "pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page: :-s Print summary information about total swap :

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Noriyuki Soda
> On Thu, 15 Jul 1999, Daniel C. Sobral wrote: >> Uh... like any modern unix, Solaris overcommits. > On Thu, 15 Jul 1999 08:46:36 -0700 (PDT), "Eduardo E. Horvath" <[EMAIL PROTECTED]> said: > Where do you guys get this misinformation? : > Note the `19464k reserved'; that sp

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 17:53:10 -0700 (PDT), Matthew Dillon said: > You keep on saying that users can run the system out of swap > easily, and I've tried to point out to you that it isn't quite > as easy as you believe (and I've used a real-life example to > show my poi

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT), Matthew Dillon said: > With today's modern high capacity disk drives, a properly configured > multi-user system will have enough swap that running it out is difficult > to say the least. That's wrong. Please remember that you sa

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 17:53:10 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > You keep on saying that users can run the system out of swap > easily, and I've tried to point out to you that it isn't quite > as easy as you believe (and I've used a real-life example

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 15:53:43 -0700 (PDT), Matthew Dillon said: > ... a situation which will never occur if you are managing the memory > through your own custom library. Therefore not relevant. Hm. It's misunderstanding. I don't agree with you about the following point. T

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > With today's modern high capacity disk drives, a properly configured > multi-user system will have enough swap that running it out is difficult > to say the least. That's wrong. Please

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 15:53:43 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > ... a situation which will never occur if you are managing the memory > through your own custom library. Therefore not relevant. Hm. It's misunderstanding. I don't agree with you about th

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 15:29:37 -0700 (PDT), Matthew Dillon said: > In the same manner any truely critical system server must handle the > resource management itself to deal with all sorts of problem situations, > including memory. You do not need to build any of this cont

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 14:53:43 -0700 (PDT), Matthew Dillon said: > If you are talking about a user intentionally attempting to run > a system out of swap, it is fairly easy to do whether the system > uses an overcommit model or not. The user has any number of > ways o

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 15:29:37 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > In the same manner any truely critical system server must handle the > resource management itself to deal with all sorts of problem situations, > including memory. You do not need to bu

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 14:27:54 -0700 (PDT), Matthew Dillon said: > > That's wrong. > > On such systems, critical server has a chance to save it's data to > > filesystem. > > On 4.4BSD derived systems, it cannot be guaranteed. > You are assuming that the situation actually occurs.

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 14:16:54 -0700 (PDT), Matthew Dillon said: > > Unlike 4.4BSD derived VM, Solaris VM has a way to reserve backing store. > Secondly, for such a server to fail to run is just as bad as if > the system were to run out of swap. > IRIX has a swap reserva

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 14:53:43 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > If you are talking about a user intentionally attempting to run > a system out of swap, it is fairly easy to do whether the system > uses an overcommit model or not. The user has any nu

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 11:13:49 -0700 (PDT), Matthew Dillon said: > Doh! Even solaris doesn't overcommit - you think it actually > reserves data blocks for its file-backed swap? Bzzt! It uses > an overcommit model too. Unlike 4.4BSD derived VM, Solaris VM has a way to r

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 14:27:54 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > > That's wrong. > > On such systems, critical server has a chance to save it's data to > > filesystem. > > On 4.4BSD derived systems, it cannot be guaranteed. > You are assuming that the situat

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 14:16:54 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > > Unlike 4.4BSD derived VM, Solaris VM has a way to reserve backing store. > Secondly, for such a server to fail to run is just as bad as if > the system were to run out of swap. > IRI

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 11:13:49 -0700 (PDT), Matthew Dillon <[EMAIL PROTECTED]> said: > Doh! Even solaris doesn't overcommit - you think it actually > reserves data blocks for its file-backed swap? Bzzt! It uses > an overcommit model too. Unlike 4.4BSD derived VM, Solar

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 10:11:14 -0400 (EDT), "Brian F. Feldman" said: >> > you also have to consider a program wishing to make sparse use >> > of its address space, without overcommit it becomes impossible. >> >> SVR4 has MAP_NORESERVE option for mmap(2) for this. >> So, default behai

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> On Tue, 13 Jul 1999 10:11:14 -0400 (EDT), "Brian F. Feldman" <[EMAIL PROTECTED]> said: >> > you also have to consider a program wishing to make sparse use >> > of its address space, without overcommit it becomes impossible. >> >> SVR4 has MAP_NORESERVE option for mmap(2) for this.

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. If the system has real vfork(2) like NetBSD, this is not problem. > you also have to consider a program wishing to make sparse use > of its address space, without

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Noriyuki Soda
> You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. If the system has real vfork(2) like NetBSD, this is not problem. > you also have to consider a program wishing to make sparse use > of its address space, without