On Wed, 14 Jul 1999 15:54:22 +0900,
Seigo Tanimura said:
tanimura> Thus a callout will have an average delay of 0.5/hz = 50ms. This is
5ms, I mean...
Seigo Tanimura
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
On Tue, 13 Jul 1999, Jon Ribbens wrote:
> 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
: 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 in
Hi :)
put the following line in your kernel config file .. recompile your
kernel .. boot .. and then try the make again ...
pseudo-device vn1
to create the floppy ... a vertual node is used ..
hope this helps ...
Reinier
> During a make release for 3.2-RELEASE I get the following err
On Tue, 13 Jul 1999, Ted Faber wrote:
> 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 imple
On Wed, Jul 14, 1999 at 05:43:21PM +0930, Kris Kennaway wrote:
>
> You know, it occurred to me that with all the time wasted typing up messages
> in this thread someone (e.g. Matt) could have instead coded up a simple
> non-overcommit model, given it to the nay-sayers and said "Run this and see
> w
this message may have been posted to hacks but I didnt see it come through.
I greatly apreciate any help.
I have a WaveLAN ISA adaptor.
I am trying to run it in a machine equiped with an AMD K6-2 350
processor running at 66mhz bus speed.
I am getting the following error while ifconfiging the card
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
# These are currently broken and are no longer shipped due to lack
# of interest.
#optionsCCITT #X.25 network layer
#optionsISO
#optionsTPIP#ISO TP class 4 over IP
#optionsTPCONS #
Date:Tue, 13 Jul 1999 15:19:43 -0700 (PDT)
From:Matthew Dillon
Message-ID: <199907132219.paa81...@apollo.backplane.com>
| There are a billion ways to do it and none of them require a swap
| reservation model.
Every method you described was exactly a swap
Date:Tue, 13 Jul 1999 15:37:26 -0700 (PDT)
From:Matthew Dillon
Message-ID: <199907132237.paa81...@apollo.backplane.com>
| allocation - most everything is statically allocated and if the system
| tries to use more, it panics and reboots.
I'm finding it dif
Date:Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
From:Matthew Dillon
Message-ID: <199907132114.oaa80...@apollo.backplane.com>
| If you don't have the disk necessary for a standard overcommit model to
| work, you definitely do not have the disk necessary for a
n
> I'm not sure if XPG4v2 requires command substitution to behave
> like that. At least, both Solaris' and DEC UNIX... oops...
> True64 UNIX do execute all command substitutions in a subshell
> (`pwd` does not affect the surrounding shell), and both claim
> XPG4 compliance.
They only execute a su
> Maybe if I call the sysctl "vm.crashmenow". No, that will just make more
> people actually try it. It might be doable as a compile-time option,
> since you wouldn't be able to run anything approaching standard on
> such a system anyway. I don't see much use for it myself. As I
David Miller wrote:
>
> Couple of questions which are pretty much off topic
>
> 1) Does anyone know of a way to talk to a remote oracle server via odbc or
> oci? Access is required specifically under apache and mod_perl or php,
> but we've spent a couple of man-days looking for straightforwa
According to Kris Kirby:
> If they are not shipped, where am I to go to find them?
In the CVS repository. In the Attic of the various subdirectories.
290 [13:04] robe...@keltia:src/sys> ls
Makefile,v ddb/miscfs/ netiso/ posix4/
alpha/ dev/modu
I have a process that forks several times, I want to change the names that the
child processes appear as in the process table. Is there a trick to doing
this?
Thanks,
Wayne
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
setproctitle(3)
Wayne Cuddy wrote:
>
> I have a process that forks several times, I want to change the names that the
> child processes appear as in the process table. Is there a trick to doing
> this?
>
> Thanks,
> Wayne
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscri
Ladavac Marino wrote:
>
> This topic has been trashed to death a few months ago. There is no
> win-win situation in presence of processes which allocate a lot of memory
> without actually using it (read: your typical FORTRAN library).
This is not about just Fortran libraries. Imagine a r
In C, change argv. Be carefull to not write any strings that are longer
then the space available, or replace the pointers.
Nick
On Wed, 14 Jul 1999, Wayne Cuddy wrote:
> I have a process that forks several times, I want to change the names that
> the
> child processes appear as in the proc
Noriyuki Soda wrote:
>
> Running out of swap can be easily done by normal user privilege.
> Non-overcommiting system can run important application on the system
> which has a normal user, because it never lose critical data, even if
> a user on the system make a mistake. (The application might sto
[cutting down on cc's]
"Chris G. Demetriou" wrote:
>
> I'd _really_ like to know how you figure this.
>
> textdatabss dec hex filename
> 45024 4096392 49512 c168/bin/cat
> 311264 12288 9900333452 5168c /bin/sh
> 212960 409628492 245548 3bf2c
Doug Rabson writes:
> Overcommit can be used for many reasons. I use it to reserve a large
> linear address space to mmap alpha i/o spaces [...]
Overcommit can be used for many reasons, but unless you've
misdescribed what you're doing, _that's not one of them_.
The mapped I/O pages need no backi
"Charles M. Hannum" wrote:
>
> That's also objectively false. Most such environments I've had
> experience with are, in fact, multi-user systems. As you've pointed
> out yourself, there is no combination of resource limits and whatnot
> that are guaranteed to prevent `crashing' a multi-user syst
I realize it's not real high on the list of things to fix, but proxy ARP
is still broken in -STABLE. If anyone know the answers to any of these
questions, please drop me a line so I can try fixing it:
1) Can anyone explain the difference between "published" ARP table
entries, and "published (p
> "Matthew" == Matthew Dillon writes:
Matthew> Maybe if I call the sysctl "vm.crashmenow". No, that will
just make more
Matthew> people actually try it. It might be doable as a compile-time
option,
Matthew> since you wouldn't be able to run anything approaching
st
"Charles M. Hannum" wrote:
>
> There are many environments where even the possibility of the
> simulation crashing due to external influence is unacceptable. I find
> it sad that you resist making FreeBSD robust against such problems,
> but that's your concern.
FreeBSD is robust against the prob
Robert Elz wrote:
>
> Date:Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
> From:Matthew Dillon
> Message-ID: <199907132114.oaa80...@apollo.backplane.com>
>
> | If you don't have the disk necessary for a standard overcommit model
> to
> | work, you definitely do
On Thu, 15 Jul 1999, Daniel C. Sobral wrote:
> "Charles M. Hannum" wrote:
> >
> > That's also objectively false. Most such environments I've had
> > experience with are, in fact, multi-user systems. As you've pointed
> > out yourself, there is no combination of resource limits and whatnot
> > t
On Wed, 14 Jul 1999, Michael Richardson wrote:
>
> > "Matthew" == Matthew Dillon writes:
> Matthew> Maybe if I call the sysctl "vm.crashmenow". No, that will
> just make more
> Matthew> people actually try it. It might be doable as a
> compile-time option,
> Matthew>
I am helping a freind install FreeBSD on his machine
(it is running 4.0-CURRENT now). everything works flawlessly, except his
OEM BrookTree 848 based soundcard. The card itself is transplanted from
his gateway machine (where it also had the same problems). Here are some
specifics:
(summary)
Ma
Can someone familiar with the new threads code tell me what is causing the
following segmentation fault. Thanks.
-Kip
Program terminated with signal 11, Segmentation fault.
#0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
at /usr/src/lib/
At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote:
> 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 n
Niall Smart wrote in list.freebsd-hackers:
>
> > I'm not sure if XPG4v2 requires command substitution to behave
> > like that. At least, both Solaris' and DEC UNIX... oops...
> > True64 UNIX do execute all command substitutions in a subshell
> > (`pwd` does not affect the surrounding shell),
Even though I am developing on FBSD is there a "more portable" way to do this?
Thanks,
Wayne
On Wed, 14 Jul 1999, Andy Doran wrote:
> Date: Wed, 14 Jul 1999 15:03:55 +0100
> From: Andy Doran
> To: wa...@crb-web.com
> Cc: FreeBSD Hackers List
> Subject: Re: changing argv[0] after fork()
>
> s
"Chris G. Demetriou" wrote:
>
...
> Overcommit avoidance may not be useful for your particular uses of
> these UNIX-like systems. However, if you think that it's not useful
> to anybody who uses them (or that people who think it's useful are
> deluding themselves 8-), then you're sorely mistaken
Matthew Dillon wrote:
>
> :
> :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 th
Jason Thorpe wrote:
>
> > There is a lot of hidden 'potential' VM that you haven't considered.
> > For example, if the resource limit for a process's stack is 8MB, then
> > the process can potentially allocate 8MB of stack even though it may
> > actually only allocate 32K of st
At 12:00 PM -0400 7/14/99, Brian F. Feldman wrote:
> So why don't we do something else: when we're down to a certain
> amount of backing store, start collecting statistics. When we're
> out, we check the statistics and find what process has been
> allocating most of it. We kill that process.
Not t
Jason Thorpe wrote:
>
> That's just silly. If people want a no-overcommit system, they have it,
> and if they don't, they have that, too.
>
> That's why you make it a switch. No, really, you *can* just make it
> a switch.
So, enlighten me, please... how do you switch it in NetBSD?
--
Daniel C
At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> In which case the program that consumed all memory will be killed.
> The program killed is +NOT+ the one demanding memory, it's the one
> with most of it.
But that isn't always the best process to have killed off...
One of my main freebsd machi
"Brian F. Feldman" wrote:
>
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
>
> So why don't we do something else: when we're down to a certain amount of
> backing store, start colle
-BEGIN PGP SIGNED MESSAGE-
Garance A Drosihn wrote:
>At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
>> In which case the program that consumed all memory will be killed.
>> The program killed is +NOT+ the one demanding memory, it's the one
>> with most of it.
>
>But that isn't always
Wayne Cuddy wrote:
> Even though I am developing on FBSD is there a "more portable" way to do this?
setproctitle(3) works at least for FreeBSD and NetBSD. Poke around the
sources of sendmail(8) for a more ... ported way. I'm sure you'll find
something.
- ad
To Unsubscribe: send mail to majo
Garance A Drosihn wrote:
>
> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
>
> But that isn't always the best process to have kil
On Jul 15, 12:20am, "Daniel C. Sobral" wrote:
} "Charles M. Hannum" wrote:
} >
} > That's also objectively false. Most such environments I've had
} > experience with are, in fact, multi-user systems. As you've pointed
} > out yourself, there is no combination of resource limits and whatnot
} > t
> I mean, jeeze, the reservation for the program stack alone would eat
> up all your available swap space! What is a reasonable stack size? The
> system defaults to 8MB. Do we rewrite every program to specify its own
> stack size? How do we account for architectural differences
On Wed, 14 Jul 1999 13:28:07 -0400, Wayne Cuddy wrote:
> Even though I am developing on FBSD is there a "more portable" way to
> do this?
See the STANDARDS section of the setproctitle(3) manpage. If you worry
that you may port to an operating system whose setproctitle() has a
different calling
> Can someone familiar with the new threads code tell me what is causing the
> following segmentation fault. Thanks.
>
> -Kip
>
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
>
If you wanted to fix this, you could add a patch to malloc that touched
every page that it handed to the application. (and trapped sig11s)
On Wed, 14 Jul 1999 lyn...@orthanc.ab.ca wrote:
>
> > I mean, jeeze, the reservation for the program stack alone would eat
> > up all your available
On Wed, 14 Jul 1999, Garance A Drosihn wrote:
> At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote:
> > 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
At 1:28 PM -0400 7/14/99, Wayne Cuddy wrote:
> Even though I am developing on FBSD is there a "more portable" way
> to do this?
The man page for setproctitle(3) notes that none of the ways to do
this are necessarily portable to other systems. That said, I have
a routine from a lambdaMOO program w
Ted Faber
>For every strategy there's a counterstrategy.
exactly: the disappointing thing about this whole thread is there's been
little discussion of implementing a (tunable) policy how to handle the
situation when resource shortage materialises.
Overcommitment can be useful, maybe even for most
On Wed, 14 Jul 1999, Daniel Eischen wrote:
> > Can someone familiar with the new threads code tell me what is causing the
> > following segmentation fault. Thanks.
> >
> > -Kip
> >
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0 0x82fb15
> So why don't we do something else: when we're down to a certain amount of
> backing store, start collecting statistics. When we're out, we check the
> statistics and find what process has been allocating most of it. We kill
> that process.
Our IMAP server routinely show a footprint of about 1MB
I just rebuilt libc_r and relinked my application. I am now crashing right
away as opposed to after several hours as I have been.
Program terminated with signal 11, Segmentation fault.
#0 0x82fa07c in _thread_kern_sched_state_unlock ()
(gdb) bt
#0 0x82fa07c in _thread_kern_sched_state_unlock ()
You don't seem to understand that a runaway process/one designed just
to take up memory will be much more active than your little IMAP servers,
and be the one killed, if this scheme were used.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ __
Kip Macy wrote:
> > In the mean time, you can grab libc_r/uthread/* from -current
> > and rebuild libc_r under -stable.
>
> Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a
> result of a problem with infinite recursion in write. When was this bug
> fixed?
The fix for static
> You don't seem to understand that a runaway process/one designed just
> to take up memory will be much more active than your little IMAP servers,
> and be the one killed, if this scheme were used.
No, what I don't understand is how the current behaviour can tell that
my temporary and *valid* ne
Kip Macy wrote:
> I just rebuilt libc_r and relinked my application. I am now crashing right
> away as opposed to after several hours as I have been.
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x82fa07c in _thread_kern_sched_state_unlock ()
> (gdb) bt
> #0 0x82fa07c in _thre
On Mon, Jul 12, 1999 at 01:22:49PM -0700, Julian Elischer wrote:
< talking about the recent paper on using KLDs to replace FreeBSD syscalls >
> I would suggest that a version of this document be incorporated into our
> docs.
I've already e-mailed the people concerned to ask. I'll let you know w
At 2:40 AM +0900 7/15/99, Daniel C. Sobral wrote:
>Garance A Drosihn wrote:
>>
>> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
>> > In which case the program that consumed all memory will be killed.
>> > The program killed is +NOT+ the one demanding memory, it's the one
>> > with most of it.
On 14 Jul 1999, Chris G. Demetriou wrote:
> Doug Rabson writes:
> > Overcommit can be used for many reasons. I use it to reserve a large
> > linear address space to mmap alpha i/o spaces [...]
>
> Overcommit can be used for many reasons, but unless you've
> misdescribed what you're doing, _that'
> What you don't understand is that no process is going to die unless either
> someone is running away (in which case they'll get the bullet) or your
> system is horribly misconfigured (in which case you deserve your fate).
*Why* the machine is out of memory is not the issue. The issue is
what ha
On Wed, Jul 14, 1999 at 12:52:38AM -0600, Warner Losh wrote:
> 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
On Thu, 15 Jul 1999, Daniel C. Sobral wrote:
> For the record, professional digital cameras go into the $100K
> range, so I'd be expecting it not only to run Apache, but also to
> come with Doom. :-)
Well you have 16MB RAM, 32MB flash memory, a network interface,
other bits and Ne
In message <19990714185101.09...@goatsucker.org>, Scott Mitchell writes:
>Ugh. In that case, can someone back out Poul-Henning's changes to the
>if_xe.c in the -STABLE tree?
Uhm my change has not been applied to STABLE, but the 3.2-PAO import
references current rather than stable.
--
Poul-Henni
On Jul 15, 12:53am, "Daniel C. Sobral" wrote:
} Robert Elz wrote:
} >
} > From:Matthew Dillon
} >
} > | If you don't have the disk necessary for a standard overcommit
model to
} > | work, you definitely do not have the disk necessary for a
non-overcommit
} > | mod
> "John" == John Nemeth writes:
John> On one system I administrate, the largest process is typically
John> rpc.nisd (the NIS+ server daemon). Killing that process would be a
John> bad thing (TM). You're talking about killing random processes.
John> This is no way to run a sy
On Jul 15, 2:40am, "Daniel C. Sobral" wrote:
} Garance A Drosihn wrote:
} > At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
} > > In which case the program that consumed all memory will be killed.
} > > The program killed is +NOT+ the one demanding memory, it's the one
} > > with most of it.
}
> "Ben" == Ben Rosengart writes:
Ben> On Wed, 14 Jul 1999, John Nemeth wrote:
>> On one system I administrate, the largest process is typically
>> rpc.nisd (the NIS+ server daemon). Killing that process would be a
>> bad thing (TM). You're talking about killing random proce
Hi,
I'm trying to dynamically determine the tcp windowsize. Sysctl
has the following to say, but the name/value pairs are not
documented.
net.inet.tcp.rfc1323: 0
net.inet.tcp.rfc1644: 0
net.inet.tcp.mssdflt: 512
net.inet.tcp.rttdflt: 3
net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150
n
On Jul 14, 5:57pm, Ben Rosengart wrote:
} On Wed, 14 Jul 1999, John Nemeth wrote:
}
} > On one system I administrate, the largest process is typically
} > rpc.nisd (the NIS+ server daemon). Killing that process would be a
} > bad thing (TM). You're talking about killing random processes.
> Hi,
>
>I'm trying to dynamically determine the tcp windowsize. Sysctl
> has the following to say, but the name/value pairs are not
> documented.
>
> net.inet.tcp.sendspace: 16384
> net.inet.tcp.recvspace: 16384
...
>send/recv space might be what I'm looking for...
They're the default s
:> net.inet.tcp.recvspace: 16384
:...
:>send/recv space might be what I'm looking for...
:
:They're the default send/receive window sizes, yes. You can tweak them
:with socket ioctls on a per-socket basis.
:
:>delayed ack sounds interesting
:
:Turning that off disables TCP slow-start.
Date:Thu, 15 Jul 1999 00:53:17 +0900
From:"Daniel C. Sobral"
Message-ID: <378cb26d.c0bc0...@newsguy.com>
| Would you care to name such systems?
munnari was one (the system of the From: header, even though this
mail isn't actually going anywhere near it). I will d
>>delayed ack sounds interesting
>
>Turning that off disables TCP slow-start. It's a huge performance
>booster for things like SMB service, where you have lots of short-lived
>TCP connections on a local net.
Uh, that's not what it does. Slow start is a behavior where the sender
opens
:Now let's look at what happens with the two methods.
:
:With all VM backed by real mem or swap space, processes go about allocating
:memory - when there is no more left, the allocations start failing.
:If the process is perl, it just collapses in a heap, and the log file
:summary doesn't get made
In article
you write:
>>delayed ack sounds interesting
>
>Turning that off disables TCP slow-start. It's a huge performance
>booster for things like SMB service, where you have lots of short-lived
>TCP connections on a local net.
Mike probably already knows this, but just a general cl
Do you want an executable?
Anyway, I compiled the tests in /usr/src/lib/libc_r/test/ and they both
seg faulted in the exact same way:
Note: I had to add the -static to the LDFLAGS in order for gdb to find
symbols for them.
adsl-216-101-22-188 [libc_r/test/sigwait|14:14|210|]gdb sigwait
sigwai
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
John Baldwin wrote:
> What does that have to do with overcommit? I student administrate a
> undergrad
> CS lab at a university, and when student's programs misbehaved, they
> generate a
> fault and are killed. The only machines that reboot on us
> Also, your named is badly misconfigured if it grows to 130MB. We never
> allow ours to grow past 30MB.
How do you know what kind of name server configuration kre is running?
Here's an example of a name server running *non-recursive*, serving
11.500 zones:
PID USERNAME PRI NICE SIZE
:
:> Also, your named is badly misconfigured if it grows to 130MB. We never
:> allow ours to grow past 30MB.
:
:How do you know what kind of name server configuration kre is running?
:Here's an example of a name server running *non-recursive*, serving
:11.500 zones:
:
: PID USERNAME PRI
:On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
: John Baldwin wrote:
:
: > What does that have to do with overcommit? I student administrate a
undergrad
: > CS lab at a university, and when student's programs misbehaved, they
generate a
: > fault and are killed. The only machines that reboot on us
In message <19990714185101.09...@goatsucker.org> Scott Mitchell writes:
: Ugh. In that case, can someone back out Poul-Henning's changes to the
: if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it
: from working. At least that way only my code will be bogus :-) Believe
: me
On Wed, 14 Jul 1999 12:43:07 +
Niall Smart wrote:
> Perhaps it could be an additional flag to mmap, in this way
> people wishing to run an overcommited system could do so
> but those writing programs which must not overcommit for
> certain memory allocations could ensure they did not do
On Thu, 15 Jul 1999 01:52:11 +0900
"Daniel C. Sobral" wrote:
> > ...um, so, make the code that deals with faulting in the stack a bit
> > smarter.
>
> Uh? Like what? Like overcommitting, for instance? The beauty of
> overcommitting is that either you do it or you don't. :-)
One option i
On Thu, Jul 08, 1999 at 10:22:47PM +0100, Nik Clayton wrote:
> Tim Singletary has written some man pages for the dbm_* functions in libc,
> which are currently undocumented -- we know they are written in terms
> of dbopen(), but it's nice to have them documented anyway.
>
> Could anyone who knows
On Thu, 15 Jul 1999 01:59:12 +0900
"Daniel C. Sobral" wrote:
> > That's why you make it a switch. No, really, you *can* just make it
> > a switch.
>
> So, enlighten me, please... how do you switch it in NetBSD?
When the code to do it is implemented (not that hard, really, and it is
in th
On Tue, Jul 13, 1999 at 05:12:30PM -0700, Matthew Dillon wrote:
> Ok, I will be more specific.
>
> Under FreeBSD-STABLE *AND* FreeBSD-CURRENT, FreeBSD allocates metadata
> structures that scale to the amount of swap space assigned to the system.
> However, it is not *precisely* the
On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote:
> 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/f
:
:One option is to special-case overcommit the stack. Another is to
:set the default stack limits to something more reasonable on a system
:where overcommit is disabled.
:
:-- Jason R. Thorpe
Try setting all the resource limits to something reasonable on general
principles. It
[ Trimmed CC list a bit ]
> > :* even if you are not willing to pay that price, there _are_ people
> > :who are quite willing to pay that price to get the benefits that they
> > :see (whether it's a matter of perception or not, from their
> > :perspective they may as well be real) of such a scheme
On Fri, Jul 09, 1999 at 11:39:38AM +0200, Sheldon Hearn wrote:
> On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote:
> > With that in mind, how about this patch (in conjunction with the patch to
> > login.conf in the original PR, which just updates a comment)?
>
> This looks much better. :-)
C
:> >
:> > Quite true. In the embedded world we preallocate memory and shape
:> > the programs to what is available in the system. But if we run out
:> > of memory we usually panic and reboot - because the code is designed
:> > to NOT run out of memory and thus running out of memo
> :> > Quite true. In the embedded world we preallocate memory and shape
> :> > the programs to what is available in the system. But if we run out
> :> > of memory we usually panic and reboot - because the code is designed
> :> > to NOT run out of memory and thus running out of me
> In article
> you write:
> >>delayed ack sounds interesting
> >
> >Turning that off disables TCP slow-start. It's a huge performance
> >booster for things like SMB service, where you have lots of short-lived
> >TCP connections on a local net.
>
> Mike probably already knows this, but
:
:Most of the work we've done wouldn't allow this, especially if we were
:using an OS like FreeBSD with a fairly long bootup time. Especially if
:it can be avoided.
:
:Yes, we could (and did) do our own memory management, but it seems to me
:that the kernel has alot more information available to
> :Most of the work we've done wouldn't allow this, especially if we were
> :using an OS like FreeBSD with a fairly long bootup time. Especially if
> :it can be avoided.
> :
> :Yes, we could (and did) do our own memory management, but it seems to me
> :that the kernel has alot more information ava
:
:Returning NULL isn't an error, it's an indication that there is no more
:memory. Don't think if it as an error, think of it as a hint.
It's only a hint if it is returned due to the process resource limit
being hit. If it is returned due to the system running out of swap,
it would
1 - 100 of 261 matches
Mail list logo
