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
:> 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" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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).
>>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
open
: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 [EMAIL PROTECTED]> 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, bu
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
sigwa
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
John Baldwin <[EMAIL PROTECTED]> 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
> 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 SIZ
:
:> 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 <[EMAIL PROTECTED]> 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
In message <[EMAIL PROTECTED]> 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, I know it's ugl
On Wed, 14 Jul 1999 12:43:07 +
Niall Smart <[EMAIL PROTECTED]> 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 en
On Thu, 15 Jul 1999 01:52:11 +0900
"Daniel C. Sobral" <[EMAIL PROTECTED]> 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. :-)
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" <[EMAIL PROTECTED]> 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, rea
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* th
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/
:
: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 <[EMAIL PROTECTED]>
Try setting all the resource limits to something reasonable on general
[ 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 schem
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. :-)
:> >
:> > 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 mem
> :> > 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 m
> In article [EMAIL PROTECTED]> 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 alrea
:
: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 av
:
: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 woul
> :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,
>
Hi,
I have some minor probem with my CMI8330 chip based integrated sound
card on m726 motherboard.
Here's the URL where you can find how to fix it:
http://www.cslab.vt.edu/~jobaldwi/cmi8330init.tar.gz
= cut here =
Thank you very much for your problem report.
It has th
On 1999/07/14 at 11:17pm +0900, "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
>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: yo
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 ki
At 3:18 PM -0700 7/14/99, Matthew Dillon wrote:
>This conversation is getting silly. Do you actually believe
>that an operating system can magically protect itself 100%
>from armloads of hostile users?
>
>Give me a break. You people are crazy. If you have something
>worthwhi
On Thu, 15 Jul 1999, Harold Gutch wrote:
> 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, pident
:For the moment I'll pretend that you honestly think that is an
:answer, and I'll note that the very same machine may have well
:over 100 processes each of which takes 1-2 meg of memory. If
:the machine hits a really-out-of-memory error, I would be much
:much happier to see all 100+ of those proc
In message <[EMAIL PROTECTED]> Wayne Cuddy
writes:
: Even though I am developing on FBSD is there a "more portable" way to do this?
No. Well, not short of execing.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[EMAIL PROTECTED] wrote:
> The semantics of malloc() have been defined since almost the dawn of
> time. From the current manpage:
> RETURN VALUES
> The malloc() and calloc() functions return a pointer to the allocated
> memory if successful; otherwise a NULL pointer is returned.
Is the reason why adb hasn't been ported to freebsd because the source is
proprietary?
If gdb should suffice for my debugging needs, how can a breakpoint be set
at a particular interrupt, or even at any interrupt? The break command
only seems to accept functions, offsets, linenumbers and addresse
Garance A Drosihn wrote:
>
> >> One of my main freebsd machines is mainly here to run one
> >> process, which is a pretty good-sized process (>40meg). If
> >> I did get into a memory-shortage problem, I do *not* want
> >> that process killed, I'd want some other processes killed.
> >
> > Just si
John Nemeth wrote:
>
> } > This is based upon your somewhat strange definition of "work". I assure
> } > you that I have run many systems which don't use overcommit, and which I
> } > quite frequently run into "out of VM" conditions, and which I can assure
> } > you, work just fine. When they
John Nemeth wrote:
>
> } > But that isn't always the best process to have killed off...
> }
> } Sure it is. :-) Let's see...
>
> This statement is absurd. Only a comptetant admin can decide
> which process can be killed. No arbitrary decision is going to be
> correct.
We are talking abou
Robert Elz wrote:
>
> Note that all this (large) VM I have described was filled with real data
> (except for the odd times hen innd or named had just forked), none of it
> could be overcommitted and just ignored. Whatever policy was in place,
> the physical VM resources would have run out.
In
Jason Thorpe 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 is to special-case overcommit the sta
Sergey Babkin wrote:
>
> > It would be nice to have a way to indicate that, a la SIGDANGER.
>
> Another option may be to add something like "importance classes".
> Suppose we assign an one-byte "importance level" to each process.
> When we get out of swap we start killing processes with the lowe
:Our IMAP server routinely show a footprint of about 1MB private storage.
:This is constant for most operations. However, when you get into doing
:SEARCH and SORT, there are certain cases where we need memory, sometimes
:a *lot* of memory.
:
:Your proposal is that my *well behaved* application sho
:Ted Faber <[EMAIL PROTECTED]>
:>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
:> 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 differe
:
: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 wha
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. This
> is no way to run a system. It is not possible for any arbitra
Michael Richardson wrote:
>
> No, I don't agree.
>
> This is a biggest argument against solving the overcommit situation with
> SIGKILL. I have no problem with overcommit as a concept, I have a problem
> with being unable to keep my possibly big processes (X, rpc.nisd,
> etc. depending on ci
Michael Richardson wrote:
>
> Ben> Tell me, Mr. Nemeth, has this ever happened to you? Have you ever
> Ben> come *close*?
>
> Uh, since we don't run overcommit, the answer is specifically *NO*.
And what system do you run?
> I have had it happen on other systems. (Solaris, AIX) It
John Nemeth wrote:
>
> The machine in question has run out of swap, due to unforseeable
> excessive memory demands. This was accompanied by processes
> complaining about not being able to allocate memory and then cleaning
> up after themselves. I did not see random processes being killed
>
[EMAIL PROTECTED] wrote:
>
> What it so evil about having a reasonably intelligent malloc() that
> tells the truth, and returns unused memory to the system? Overcommit
> is for lazy programmers, plain and simple. At least the SGI documentation
> about overcommit admits that (or at least, did at o
Jason Thorpe wrote:
>
> If you have a lot of users, all of which have buggy programs which eat
> a lot of memory, per-user swap quotas don't necessarily save your butt.
The chance of these buggy programs running at the same time is not
exactly high...
> And maybe the individual programs didn't
>
> And what do you do, then, with the processes that happen to have
> legitimate use for more stack?
>
> Or maybe you just find out how much stack each process uses, and
> then set limits appropriate for each one? Which is the equivalent of
> setting limits to each user, of course...
You get a
> Is the reason why adb hasn't been ported to freebsd because the source is
> proprietary?
You make no sense.
> If gdb should suffice for my debugging needs, how can a breakpoint be set
> at a particular interrupt, or even at any interrupt? The break command
> only seems to accept functions, off
On Thu, Jul 15, 1999 at 01:48:40PM +0900, Daniel C. Sobral wrote:
> >
> > If you have a lot of users, all of which have buggy programs which eat
> > a lot of memory, per-user swap quotas don't necessarily save your butt.
>
> The chance of these buggy programs running at the same time is not
> ex
> 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.
Daniel Eischen <[EMAIL PROTECTED]> writes:
> There are some bugs in libc_r in stable that have been fixed in
> -current. I think the one that you've hit is an uninitialized
> TAILQ_HEAD in a statically declared mutex (in localtime). It's
> probably about time for a MFC. If someone wants to giv
Mike Smith wrote:
>
> > 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 tha
Hi everyone,
I've been following this discussion almost from the beginning, and I
have the feeling that we're not _really_ getting very far. There's good
arguments for and against overcommit, depending on your point of view
and your requirements.
What I do see is a not-so-openly voiced consent t
201 - 261 of 261 matches
Mail list logo
