:> [ML] It is possible to handle these cases in VM code, by
:> trapping on any access to the partial page, and allowing only those
:> accesses which are withing the originally requested range. Performance
:> would suck without end, though.
:
:Well it would only suck for access to that p
got to set error = 0.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:Matt,
:If you agree with this patch to your patch
:I'll commit the NFS fixes to 3.x
:(I'll also add this change to the 4.0 version.)
:
:***
:[...]
:
:I guessed I freaked some people out when I declared that I wanted to
:work on the VM system, discussions in the first few months went with
:half of core talking to me like I didn't know jack when I do know at
:least jack, but had to come up to speed on FreeBSDisms
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:And no, I don't voluneer to do it all by myself, although I'd be glad
:to help, coordinate the project, or even do most of the work myself
:given enough time
change out from under the program's control. Thus most programs using
mmap() simply map the file's full size and do not try to do anything
fancy.
: Kelly
: ~[EMAIL PROTECTED]~
-Matt
ool looking optimizations that
would cut NFS stat traffic in half.
I find it rather humorous that I always spend hours testing things that
other committers would commit without any testing whatsoever.
-Matt
Ok, but for a kernel hacker this *should* be funny.
My system locked up because it had too much memory. Specifically, there
is a contrived limit to the size of the kernel malloc pool of 40MB,
and 80MB for the entire pool based on VM_KMEM_SIZE_MAX.
Unfortunately, if you have
g' by not accessing data through the approved
:mechanisms) will lead to fairly obscure panics (the address is
:perfectly valid - it's just the wrong segment).
:
:Peter
-Matt
Matthew Dillon
null bs=32k count=64
2097152 bytes transferred in 0.024780 secs (84630712 bytes/sec)
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
:or do what Kirk wants to do and merge the VM and Vnode structures
:I belive the UVM does a bit in this direction due to kirk's influence.
:
:julian
If this could result in a smaller overall structure, it may be worth it.
To really make the combined structure smaller we would also have to
ew years behind the times.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
valid. It's setting a bit in the bitmask for
one of those descriptors that should return EBADF!
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:> 2. Most shell services do a good job of keeping ident reliable. They need
:> to do that because most IRC networks heavily penalize clients that don't
:> return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like "HAX0r", there is little point, exce
:How in the world could my inetd ident service be exploited? I just fixed
:the only problematic feature, fake id, to make it not read anything but a
:regular file and not let you try to use someone else's name. I can't see
:any way that any part of it could be exploited...
Typically the expl
This topic has been rehashed a thousand times.
What it comes down to is that if you want to disallow overcommit, you
have to multiply the amount of swap space in the system relative to
current levels in order to get the same performance limits as you had
before. If you don't,
at least a year
now! Usually the biggest process is the one responsible (note: MFS
processes do not count, and they are immune from being killed).
-Matt
Matthew Dillon
&l
se the swap metadata structures are simpler.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
sd.org/People/Pages/cgd.html
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:How hard would it be to add a sysctl variable that controlled whether or not
:the system would overcommit memory?
:
:-Archie
:
:___
:Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Archie, the
:
:On Tue, 13 Jul 1999 11:59:25 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > We could have the ability to mark processes as being more or less
: > preferable as kill candidates. I'm not sure I really care anymore,
: > though... there is so much
:
:>>>>> 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 ove
vents the
lockup -- you could even try turning off all logging (but leaving syslog
running, i.e. turning it into a sink-null) to see if that has an effect.
-Matt
Matthew D
a normal system with
8x swap?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
g killed by
the kernel.
:...
:-Archie
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:___
:Archie Co
:
:On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > 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
: > model to wo
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:On Tue, 13 Jul 1999 14:27:54 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > You are assuming that the situation actually occurs. In real life,
: > it will not occur unless the critical server is running away with
: > memory.
: >
: > I hav
:
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:
:> 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
:> model to work.
:
:I'd _really_ like to know how you fig
limit datasize 1m
run process A
limit datasize 10m
run process B
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAI
processes long
before they would actually run out.
There are a billion ways to do it and none of them require a swap
reservation model.
-Matt
Matthew Dillon
<[E
nting your own management of memory rather
then use the UNIX libc builtins. The UNIX libc bulitins properly assume
a more general machine configuration and it would not be appropriate to
use them for embedded work if memory use is an issue.
-Matt
:Jason Thorpe wrote:
:>
:> On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
:> Matthew Dillon <[EMAIL PROTECTED]> wrote:
:>
:> > If you don't have the disk necessary for a standard overcommit model to
:> > work, you definitely do not have the
memory reservation to operate.
In fact, these types of systems generally do not even do dynamic memory
allocation - most everything is statically allocated and if the system
tries to use more, it panics and reboots.
:On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> 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 relevan
:
: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
:>
limitations.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
rary. Therefore not relevant.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
mething inherently broken with syslogd
that is causing the lockup even with all entries commented out, or
we may well find that it is a certain line, such as the /dev/console,
root, or "*" line for emergency messages that is causing amd to lockup.
an 'overcommitted' state.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
h the level of control required.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
he latter
:makes practical.
Heh heh.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
: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
ing
the incorrect assumption that just because something *might* occur, it
*will* occur. Calculate the probability. If the probability is not
significant relative to other potential problems (like someone kicking the
power cord out of the computer), then it isn't something you should b
wired to support the swap subsystem. This usage covers
both the fixed and dynamic allocations.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail
:
: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,
; can also mean to allocate extra swap
if you believe that the runaways are common enough to cause a problem.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe:
:>>>>> 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
:>
w much swap is on this system, by the way?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
tcpfinger
80 opentcphttp
110 opentcppop3
113 opentcpauth
-Matt
Matthew Dillon
most people
don't have swap problems to begin with. It would be fairly easy
for a watcher script to catch a system heading towards swap exhaustion
because it generally takes a while to get into the swap exhaustion
state.
-Matt
current
numprocs x datasize limit
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
reds
of thousands do something but they would do a lot better with a watchdog
script. It makes no sense to try to build it into the kernel.
-Matt
Matthew Dillon
&l
ize just to idiom.com, I would have
to first create a specific route to idiom.com, then change that.
route add idiom.com default
route -n change idiom.com -sendpipe BYTES -recvpipe BYTES
-Matt
it isn't supposed to be nice. Maybe you shouldn't be depending on last
resort mechanisms to keep your machines running.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
doing other things. If the system starts to
page (which this person's system is obviously doing), then it is doubly
a bad idea to allow a named to grow that large.
-Matt
: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
eneral
principles. It would work as well in an overcommit system as it would
in a non-overcommit system.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscrib
:> >
:> > 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
from occuring in the
first place.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
: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
general idea of
:overcommitting, or whatever it is that has your shorts all tied
:up in a knot.
:
:---
:Garance Alistair Drosehn = [EMAIL PROTECTED]
:Senior Systems Programmer or [EMAIL PROTECTED]
-Matt
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
actually ever got close to using all available
swap, the other subsystems would be up the creek anyway so, really,
it doesn't make much sense hacking the source to allow the subsystem
to run into the wall anyway.
-Matt
chance of that system running out of swap space
is?
The machine has hit the wall, the admin can't login. What
is the kernel to do?
-Matt
Matthew Dillon
in order to get better interactive
performance. e.g. working over a remote connection while
at the same time downloading a big tar file via ftp or a
browser.
-Matt
Matthew Dillon
mem or /dev/io) to poll in a tight loop and collect
statistics that way.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
potentially
swappable space.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
fork occurs ).
Do a pstat -s before, after the initial touch, and after
the fork. If you do not see the reserved swap space jump
by 32MB after the fork, it isn't what you thought it was.
-Matt
Matt
n
turn it into a partition that you can then
mount and use normally.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
either allocated or reserved ( though only 12MB would be actually written,
that part doesn't change ). 439MB of swap verses 12MB of swap.
In that scenario, the 512MB of swap I assigned to this machine would be
dangerously low.
about half a dozen processes that are still
running no longer being stable. As a sysop, I would reboot a system
in such a state instantly.
-Matt
Matthew Dillon
<[EMA
s a knob to disable overcommit.
:
:--lyndon
If your machines aren't going to run out of swap, then the overcommit
isn't going to hurt you in a million years.
-Matt
came across a case where
read() could return -1 and not set errno properly if errno
was already set, but a perusal of the kernel code seems to indicate
that this can't happen. Very weird.
-Matt
files or swap partitions?
Or is it that weird /tmp filesystem stuff? If it normally uses swap
files and allows holes then that explains everything.
-Matt
Matthew Dillon
BSD's are
certified for any of that stuff that I know of.
What's next: A space shot? These what-if scenarios are getting
ridiculous.
-Matt
Matthew Dillon
on-critical sensing, but you aren't going to see it for external
communications or thruster control.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: se
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:take great care to gracefully handle these exceptions. All the C
:programs that we've ever written also take great care in handling
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
esn't.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:Cheers,
:Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __
To Unsubscribe: send mail to
: I know, I'm just wondering how did they get more frequency out of
:wire of the same size. I can understand it if the wire was a larger
:guage.
For twisted pair, Less power == less crosstalk. Plus the higher
bandwidth transceivers use better receivers and better pre-attenuation
:
:And you seen the nice square waves of 100Mb or !Gb ether on a line then? The
:techniques used for transmitting 100Mb/s down copper are certainly not digital.
:Pulse shaping, line estimation, ISI removal are all analogue!
:
:The cable itself is less improtant than the impedance matching at conn
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
able /dev/rda0a' and reboot.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:> 2.6 MB/sec is what I would expect if you were running the test
:> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
:> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
:
: That was actually done with ftp between two machines connected
:
:On 17-Jul-99 Matthew Dillon wrote:
:>
:> Obviously you don't get square waves going down the wire - But it is
:> still a digital communications protocol.
:>
:> -Matt
:
:However the physical layer, i.e. the cable, is analogue an
t have a gig of ram, MFS isn't going to help
you since the pages will be forced out to swap and cause
disk I/O to occur when they are brought back in.
-Matt
Matthew Dillon
on.
:...
: Brian Fundakowski Feldman _ __ ___ ___ ___ ___
No, you can't. All you can do is return a file descriptor. It can be
a pipe, of course, but that's still nowhere near what you need to
simulate a filesystem.
-Matt
like this.
I don't think it would be terribly difficult except for the mmap()
piece.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMA
Thus, calloc() cannot under normal circumstances assume that the data
buffer returned by malloc() is already clear. Since calloc() is not
usually used to allocate large chunks of memory, this isn't a problem.
-Matt
le is different, but almost the same size.
:
:Why is FreeBSD's file so much slower?
:
:Leif
:
:
:
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with "unsubscribe freebsd-hackers" in the body of the message
:
submaps?
:
:Thanks for any help.
:
:-Zhihui
The kmem_map and mb_map's can be modified from interrupts.
The other maps cannot.
-Matt
Matthew Dillon
<[EMAIL P
re out
what is causing the slowness.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
901 - 1000 of 1441 matches
Mail list logo
