On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson said:
dfr> If I understand this correctly, you are suggesting that we program timer0
dfr> so that we only take interrupts when a finetimer is due to fire? If so,
dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me
d
In message <19990713210337.h85...@remarq.com> Ade Lovett writes:
: This is going to be for both -current and MFC'd back into -stable, yes?
The interface for doing this I'll be merging back into -stable.
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers"
In message <19990713182203.a68...@nuxi.com> "David O'Brien" writes:
: Since no one has repsonded to this querry, I will be un-staticizing these
: so they will be available to drivers.
No. Please don't. This is the first I've seen this. There will be
another cis reading interface as part of the
: Back on topic:
:
: Obviously you devote the most time to handling the most common
: and serious failure modes, but if someone else if willing to
: put in the work to handle nightmare cases, should you ignore or
: discard that work?
Of course not. But nobody i
On Tue, 13 Jul 1999, Jon Ribbens wrote:
> 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 s
On Wed, 14 Jul 1999 15:54:22 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
tanimura> Thus a callout will have an average delay of 0.5/hz = 50ms. This is
5ms, I mean...
Seigo Tanimura <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson <[EMAIL PROTECTED]> said:
dfr> If I understand this correctly, you are suggesting that we program timer0
dfr> so that we only take interrupts when a finetimer is due to fire? If so,
dfr> then it sounds very good. The idea of taking 6000+ inte
In message <[EMAIL PROTECTED]> Ade Lovett writes:
: This is going to be for both -current and MFC'd back into -stable, yes?
The interface for doing this I'll be merging back into -stable.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of th
In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: Since no one has repsonded to this querry, I will be un-staticizing these
: so they will be available to drivers.
No. Please don't. This is the first I've seen this. There will be
another cis reading interface as part of the newbusificat
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> Jason, I am using real life situations to demonstrate my point. You are
> perfectly welcome to use your own REAL-LIFE situations to demonstrate
> yours. It is the real-life application that matters, not a worst-case
> nightmare theory
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> Jason, I am using real life situations to demonstrate my point. You are
> perfectly welcome to use your own REAL-LIFE situations to demonstrate
> yours. It is the real-life application that matters, not a worst-case
> nightmare theor
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> There are other ways. For example, even if a user account is resource
> limited, root processes (such as sendmail, popper, identd, and so forth)
> are not. Attacks against these servers generally result in very high
> loads and sometim
is there some reason why whether or not to overcommit can't be a kernel
compile time option?
Or that a process can signal its desire to not get SIGKILL by registering
a non-default SIGDANGER (which we'd have to create) handler ala AIX?
] Train travel features AC outlets with no take-off rest
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> There are other ways. For example, even if a user account is resource
> limited, root processes (such as sendmail, popper, identd, and so forth)
> are not. Attacks against these servers generally result in very high
> loads and someti
We don't _need_ pidentd anymore. It will load down a system more than
the inetd's implementation of ident will. Therefore, pidentd should be
phased out. Other than that, pidentd should be using
http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm.
Brian Fundakowski Feldman _
On 14-Jul-99 Jason Thorpe wrote:
> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
> Matthew Dillon wrote:
>
> > You have to consider the probability of an event occuring, not just
> > the possibility that the event might occur. If the probability is
> > one in a million years, then
is there some reason why whether or not to overcommit can't be a kernel
compile time option?
Or that a process can signal its desire to not get SIGKILL by registering
a non-default SIGDANGER (which we'd have to create) handler ala AIX?
] Train travel features AC outlets with no take-off res
: I've long felt that the best solution to problems like this is a per-user
:swap space quota. This gives admins a knob to manage the allocation of swap
:space while still allowing overcommit. The downside is that it doesn't provide
:a graceful way for a program to recover from it's overconsumpt
We don't _need_ pidentd anymore. It will load down a system more than
the inetd's implementation of ident will. Therefore, pidentd should be
phased out. Other than that, pidentd should be using
http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm.
Brian Fundakowski Feldman _
:> swap. How much swap is on this system, by the way?
:
:I could just as rightfully argue that you're blaming a failure of the
:OS on the sysadmin. Fiddling with limits is all fine and dandy, but
:it's not even close to flexible enough. Consider, for example, the
:specific case of testing a
>The point is, the OS should have provided *some* mechanism to insure
>that the long-running process wasn't affected. It didn't. That's a
>clear failure of the OS to provide a reasonable environment for this
>type of computing.
>
>Whether this should be solved by switching to a no-overcommit poli
On 14-Jul-99 Jason Thorpe wrote:
> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> > You have to consider the probability of an event occuring, not just
> > the possibility that the event might occur. If the probability is
> > one in a
: I've long felt that the best solution to problems like this is a per-user
:swap space quota. This gives admins a knob to manage the allocation of swap
:space while still allowing overcommit. The downside is that it doesn't provide
:a graceful way for a program to recover from it's overconsump
:Thanks for every one's help - I now have it working nicely. It's amazing what
:you discover when RTFMing. Oddly enough, running nmap with the Christmas tree
:scan (after I've allowed only smtp & ssh to be connected to) gives the
:following -
:
:# ./nmap -v -v -sX foo
:
:Starting nmap V. 2.12 by
On Tue, Jul 13, 1999 at 06:22:03PM -0700, David O'Brien wrote:
> [about cdread()/cdwrite() in /sys/pccard/pcccard.c]
>
> Since no one has repsonded to this querry, I will be un-staticizing these
> so they will be available to drivers.
This is going to be for both -current and MFC'd back into -sta
> Stephen Hocking wrote:
> you discover when RTFMing. Oddly enough, running nmap with
> the Christmas tree
> scan (after I've allowed only smtp & ssh to be connected to)
> gives the
> following -
>
> Initiating FIN,NULL, UDP, or Xmas stealth scan against foo.bar.com
> Nmap run completed -- 1
:> swap. How much swap is on this system, by the way?
:
:I could just as rightfully argue that you're blaming a failure of the
:OS on the sysadmin. Fiddling with limits is all fine and dandy, but
:it's not even close to flexible enough. Consider, for example, the
:specific case of testing a
>The point is, the OS should have provided *some* mechanism to insure
>that the long-running process wasn't affected. It didn't. That's a
>clear failure of the OS to provide a reasonable environment for this
>type of computing.
>
>Whether this should be solved by switching to a no-overcommit pol
:
:> Has your simulation ever been kicked by the kernel due to lack of
:> swap space?
:
:I already said so. Please at least pretend to read what I wrote
:before replying.
:
:There is a big difference here between a piddling web server and a
:1000-hour simulation. If the web server goes do
> The Xircom ethernet driver needs to read/write PCCARD attribute memory from
> its probe routine, in order to identify the type of card and to beat
...
> then making crdread() and crdwrite() (in /sys/pccard/pccard.c)
> non-static and calling them directly from the driver code would be an
> easy w
Thanks for every one's help - I now have it working nicely. It's amazing what
you discover when RTFMing. Oddly enough, running nmap with the Christmas tree
scan (after I've allowed only smtp & ssh to be connected to) gives the
following -
# ./nmap -v -v -sX foo
Starting nmap V. 2.12 by Fyodor
:Thanks for every one's help - I now have it working nicely. It's amazing what
:you discover when RTFMing. Oddly enough, running nmap with the Christmas tree
:scan (after I've allowed only smtp & ssh to be connected to) gives the
:following -
:
:# ./nmap -v -v -sX foo
:
:Starting nmap V. 2.12 b
On Tue, Jul 13, 1999 at 06:22:03PM -0700, David O'Brien wrote:
> [about cdread()/cdwrite() in /sys/pccard/pcccard.c]
>
> Since no one has repsonded to this querry, I will be un-staticizing these
> so they will be available to drivers.
This is going to be for both -current and MFC'd back into -st
> 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
:> 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 tha
> Stephen Hocking wrote:
> you discover when RTFMing. Oddly enough, running nmap with
> the Christmas tree
> scan (after I've allowed only smtp & ssh to be connected to)
> gives the
> following -
>
> Initiating FIN,NULL, UDP, or Xmas stealth scan against foo.bar.com
> Nmap run completed -- 1
> 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
:
:> Has your simulation ever been kicked by the kernel due to lack of
:> swap space?
:
:I already said so. Please at least pretend to read what I wrote
:before replying.
:
:There is a big difference here between a piddling web server and a
:1000-hour simulation. If the web server goes d
> I was checking out the firewall setup in /etc/rc.firewall, and noticed that
> the simple example relied on a fixed IP address for the external interface. I
> don't know ahead of time what IP address is going to be allocated to me
> before
> I dial up. Would it be possible to specify an interf
> The Xircom ethernet driver needs to read/write PCCARD attribute memory from
> its probe routine, in order to identify the type of card and to beat
...
> then making crdread() and crdwrite() (in /sys/pccard/pccard.c)
> non-static and calling them directly from the driver code would be an
> easy
:Hm. It's misunderstanding.
:
:I don't agree with you about the following point.
:Thus, the situation might happen.
:
:>Give me a shell and I can crash any machine. If you are assuming
:>hostile users, you cannot assume that your magic overcommit protection
:>will save your server. S
Thanks for every one's help - I now have it working nicely. It's amazing what
you discover when RTFMing. Oddly enough, running nmap with the Christmas tree
scan (after I've allowed only smtp & ssh to be connected to) gives the
following -
# ./nmap -v -v -sX foo
Starting nmap V. 2.12 by Fyodor
-BEGIN PGP SIGNED MESSAGE-
Matthew Dillon wrote:
>I said:
>:So, Matt, I understand that you think that the folks who are want to
>:turn off overcommit are looking to hang themselves, but how much does
>:it cost to sell them the rope?
>
>I'm guessing that a simple implementation would
:
:On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
: Matthew Dillon wrote:
:
: > You have to consider the probability of an event occuring, not just
: > the possibility that the event might occur. If the probability is
: > one in a million years, then it is not something you need to worry
On Mon, 12 Jul 1999 15:12:49 -0400, "Brian F. Feldman" wrote:
> It's "out with the bad, in with the good." Pidentd code is pretty
> terrible.
Hi Brian,
I let your comment above go at the time that you said it and I waited
for Kevin Day to substantiate similar claims. Kevin very kindly took
the
:hmmm... so this means that on my home server where I have:
:Device 1K-blocks UsedAvail Capacity Type
:/dev/od0b 26214431176 23084012%Interleaved
:/dev/da1b 39321631136 361952 8%Interleaved
:/dev/da2b 26214431072 23094412%Inter
> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
> Matthew Dillon wrote:
>
> > You have to consider the probability of an event occuring, not just
> > the possibility that the event might occur. If the probability is
> > one in a million years, then it is not something you need to
> 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
> 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
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
Matthew Dillon wrote:
> You have to consider the probability of an event occuring, not just
> the possibility that the event might occur. If the probability is
> one in a million years, then it is not something you need to worry
> a
:> 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.
:> And disallowing overcommit also does not give applications the *choice*
:> of dealing gracefully, because they often cannot deal with the
:> situation where they might be refused a reasonable request for memory.
:
:That's objectively false. The application could do something useful
Matthew Dillon scribbled this message on Jul 13:
> FreeBSD's swap subsystem has a basic limitation of 4 swap areas. This
> is due to the design of the interleaving algorithms. Increasing this
> number is simple, but it results in phenominally more kernel memory
> getting wired. W
>:
>:Well, all I can say is:
>:
>: I'm sure glad you don't have any influence over the code
>: base I run.
>:
>:-- Jason R. Thorpe
>
>I'm sure the feeling is mutual. More to the point, I really seriously
>doubt that any of the core developers would consider this idea ei
> Doug wrote:
> > John Polstra wrote:
> >>
> >> Are you sure? If you simply don't run an identd, the queries will
> >> get an instant connection refused error. That's even faster than
> >> sending back a bogus response.
> >
> > Many daemons that request ident, and almost all IRC daemons
>
> 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
> On Tue, 13 Jul 1999 16:29:50 -0700
> Mike Smith wrote:
>
> > You can make the "overcommit or not overcommit" option a switch, but
> > the consumers of the system (may) need to change their behaviour as
> > well.
>
> I never said they wouldn't have to.
"Making it just a switch" does not
> I was checking out the firewall setup in /etc/rc.firewall, and noticed that
> the simple example relied on a fixed IP address for the external interface. I
> don't know ahead of time what IP address is going to be allocated to me before
> I dial up. Would it be possible to specify an interfac
On Tue, 13 Jul 1999 16:29:50 -0700
Mike Smith wrote:
> You can make the "overcommit or not overcommit" option a switch, but
> the consumers of the system (may) need to change their behaviour as
> well.
I never said they wouldn't have to.
-- Jason R. Thorpe
To Unsubscribe: sen
> On Tue, 13 Jul 1999 16:16:07 -0700
> Mike Smith wrote:
>
> > Matt's point, which he's not making by virtue of talking too much, is
> > that you can't make a "no overcommit" system behave like an "overcommit"
> > system, and most people are used to the sort of things that the latter
> >
:On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
: Matthew Dillon wrote:
:
: > I'm sure the feeling is mutual. More to the point, I really seriously
: > doubt that any of the core developers would consider this idea either
: > because it's been rejected in the past and, so far, nobody has
:Hm. It's misunderstanding.
:
:I don't agree with you about the following point.
:Thus, the situation might happen.
:
:>Give me a shell and I can crash any machine. If you are assuming
:>hostile users, you cannot assume that your magic overcommit protection
:>will save your server.
:(Mike Smith )
:Matt's point, which he's not making by virtue of talking too much, is
:that you can't make a "no overcommit" system behave like an "overcommit"
:system, and most people are used to the sort of things that the latter
:makes practical.
Heh heh.
On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
Matthew Dillon wrote:
> I'm sure the feeling is mutual. More to the point, I really seriously
> doubt that any of the core developers would consider this idea either
> because it's been rejected in the past and, so far, nobody has offere
On Tue, 13 Jul 1999 16:16:07 -0700
Mike Smith wrote:
> Matt's point, which he's not making by virtue of talking too much, is
> that you can't make a "no overcommit" system behave like an "overcommit"
> system, and most people are used to the sort of things that the latter
> makes practica
:
:Well, all I can say is:
:
: I'm sure glad you don't have any influence over the code
: base I run.
:
:-- Jason R. Thorpe
I'm sure the feeling is mutual. More to the point, I really seriously
doubt that any of the core developers would consider this idea either
-BEGIN PGP SIGNED MESSAGE-
Matthew Dillon wrote:
>I said:
>:So, Matt, I understand that you think that the folks who are want to
>:turn off overcommit are looking to hang themselves, but how much does
>:it cost to sell them the rope?
>
>I'm guessing that a simple implementation would
:
:On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > You have to consider the probability of an event occuring, not just
: > the possibility that the event might occur. If the probability is
: > one in a million years, then it is not somethi
On Mon, 12 Jul 1999 15:12:49 -0400, "Brian F. Feldman" wrote:
> It's "out with the bad, in with the good." Pidentd code is pretty
> terrible.
Hi Brian,
I let your comment above go at the time that you said it and I waited
for Kevin Day to substantiate similar claims. Kevin very kindly took
th
:hmmm... so this means that on my home server where I have:
:Device 1K-blocks UsedAvail Capacity Type
:/dev/od0b 26214431176 23084012%Interleaved
:/dev/da1b 39321631136 361952 8%Interleaved
:/dev/da2b 26214431072 23094412%Inte
> So, Matt, I understand that you think that the folks who are want to
> turn off overcommit are looking to hang themselves, but how much does
> it cost to sell them the rope?
The issue here is that "turning off overcommit" isn't just a switch.
There are a lot of other things that you're likely
Matthew Dillon writes:
> :> ram and 512MB of swap (4MB of swap in use), but the kernel reports over
> :> 3 GB of VM assigned to processes. That's a fairly lightly loaded machine.
> :
> :What you say is generally true; however, the problem is that *you*
> :are making implicit assumptions about what
> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> > You have to consider the probability of an event occuring, not just
> > the possibility that the event might occur. If the probability is
> > one in a million years, then it is not so
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> Comment the whole thing out, kill -HUP the syslogd (or kill and restart
> it), and see if amd still locks up.
Ok, now I think I get it. You want me to enable syslog'ing in amd,
then do what you're talking about here. I will try this fir
:So, Matt, I understand that you think that the folks who are want to
:turn off overcommit are looking to hang themselves, but how much does
:it cost to sell them the rope?
:
:Would adding the sysctl to turn off overcommit be a costly,
:time-consuming hunk of work, or a three-line patch? If it's
On Tue, 13 Jul 1999, Mike Smith wrote:
> 'siobi' is someone trying to open the serial console, for whatever
> reason. Without knowing who it was that was stuck there, it's hard to
> guess what is going on.
D'uh, sorry. Long day. It was amd that was hung in the siobi
state. No way to clea
> 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
On Tue, 13 Jul 1999 15:44:40 -0700 (PDT)
Matthew Dillon wrote:
> So far nobody has been able to justify any good reasons for adding it
> to the system. I'm sorry, but just throwing out worst-case theories
> is not a good justification, nor is throwing embedded systems into the
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> You have to consider the probability of an event occuring, not just
> the possibility that the event might occur. If the probability is
> one in a million years, then it is not something you ne
-BEGIN PGP SIGNED MESSAGE-
So, Matt, I understand that you think that the folks who are want to
turn off overcommit are looking to hang themselves, but how much does
it cost to sell them the rope?
Would adding the sysctl to turn off overcommit be a costly,
time-consuming hunk of work, o
:> And disallowing overcommit also does not give applications the *choice*
:> of dealing gracefully, because they often cannot deal with the
:> situation where they might be refused a reasonable request for memory.
:
:That's objectively false. The application could do something usefu
Matthew Dillon writes:
> The text size of a program is irrelevant, because swap is never
> allocated for it. The data and BSS are only relevant when they
> are modified.
>
> The only thing swap is ever used for is the dynamic allocation of memory.
> There are three ways to do
Matthew Dillon scribbled this message on Jul 13:
> FreeBSD's swap subsystem has a basic limitation of 4 swap areas. This
> is due to the design of the interleaving algorithms. Increasing this
> number is simple, but it results in phenominally more kernel memory
> getting wired.
>:
>:Well, all I can say is:
>:
>: I'm sure glad you don't have any influence over the code
>: base I run.
>:
>:-- Jason R. Thorpe <[EMAIL PROTECTED]>
>
>I'm sure the feeling is mutual. More to the point, I really seriously
>doubt that any of the core developers would c
> Doug wrote:
> > John Polstra wrote:
> >>
> >> Are you sure? If you simply don't run an identd, the queries will
> >> get an instant connection refused error. That's even faster than
> >> sending back a bogus response.
> >
> > Many daemons that request ident, and almost all IRC daemons
>
:*.err;kern.debug;auth.notice;mail.crit /dev/console
:*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
:mail.info /var/log/maillog
:lpr.info/var/log/lpd-errs
:cron.*
:> kernel.
: :
: [snip]
: :
:> To say that FreeBSD does not support a certain class of system because
:> it uses an overcommit model is not correct, because you can trivially
:> solve the problem by implementing your own management of memory rather
:> then use
> On Tue, 13 Jul 1999, Mike Smith wrote:
>
> > > After pounding on this some more with today's -current (prior to
> > > the MNT_ASYNC flag change) I got a lot more lockups that looked like
> > > this:
> > >
> > > On Mon, 12 Jul 1999, Doug wrote:
> > >
> > > > Ok, got another hang in "
:
:Heh, really? The camera ships w/ Apache running on it.
:
:-- Jason R. Thorpe
They obviously have a lot of memory to play with, then. Or they
are crazy. Writing a web server is fairly easy to do. I've
written several, including the one that BEST runs on most of its
:
:On Tue, 13 Jul 1999, Matthew Dillon wrote:
:
:> This is an excellent example of a solution. Another example would be
:> to implement your own memory management subsystem... that is, your own
:> shared library which keeps track of memory allocations on a global
:> basis. I coul
On Tue, 13 Jul 1999, Mike Smith wrote:
> > After pounding on this some more with today's -current (prior to
> > the MNT_ASYNC flag change) I got a lot more lockups that looked like
> > this:
> >
> > On Mon, 12 Jul 1999, Doug wrote:
> >
> > > Ok, got another hang in "siobi" state (this tim
> On Tue, 13 Jul 1999 16:29:50 -0700
> Mike Smith <[EMAIL PROTECTED]> wrote:
>
> > You can make the "overcommit or not overcommit" option a switch, but
> > the consumers of the system (may) need to change their behaviour as
> > well.
>
> I never said they wouldn't have to.
"Making it jus
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> :
> : So I started thinking that maybe the problem was actually in
> :syslog (or amd's interface to it). So I disabled the following two options
> :in my amd.conf file:
> :
> :log_file = syslog:local7
> :log_options =all
> :
> 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
:On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
: Matthew Dillon wrote:
:
: > The text size of a program is irrelevant, because swap is never
: > allocated for it. The data and BSS are only relevant when they
: > are modified.
:
:Bzzt. BSS is relevant when accessed (at least in NetBSD).
On Tue, 13 Jul 1999 16:29:50 -0700
Mike Smith <[EMAIL PROTECTED]> wrote:
> You can make the "overcommit or not overcommit" option a switch, but
> the consumers of the system (may) need to change their behaviour as
> well.
I never said they wouldn't have to.
-- Jason R. Thorpe <[E
> On Tue, 13 Jul 1999 16:16:07 -0700
> Mike Smith <[EMAIL PROTECTED]> wrote:
>
> > Matt's point, which he's not making by virtue of talking too much, is
> > that you can't make a "no overcommit" system behave like an "overcommit"
> > system, and most people are used to the sort of things th
:On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > I'm sure the feeling is mutual. More to the point, I really seriously
: > doubt that any of the core developers would consider this idea either
: > because it's been rejected in the past and
On Tue, 13 Jul 1999 15:37:26 -0700 (PDT)
Matthew Dillon wrote:
> When you write embedded systems like these, you do not run any general
> purpose binaries at all. You run fully custom binaries and you take
> control of the memory management yourself.
Heh, really? The camera s
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> This is an excellent example of a solution. Another example would be
> to implement your own memory management subsystem... that is, your own
> shared library which keeps track of memory allocations on a global
> basis. I could do one
1 - 100 of 298 matches
Mail list logo
