Don Lewis said:
> On Aug 21, 2:10am, Wes Peters wrote:
> } Subject: mmap mapped segment length
> } I discovered to my dismay today that the length field in the mmap call is
> } a size_t, not an off_t. I was attempting to process a large (~50 MByte)
> file
> } and found I was only processing the
Don Lewis said:
> On Aug 21, 2:10am, Wes Peters wrote:
> } Subject: mmap mapped segment length
> } I discovered to my dismay today that the length field in the mmap call is
> } a size_t, not an off_t. I was attempting to process a large (~50 MByte) file
> } and found I was only processing the fi
Charles Randall said:
>
> Out of 128M of ram, it's swapped nearly everything else out to keep 85M of
> this 400M file in ram, even though it will never touch it again. :)
>
> I see two possible fixes for this. One could be madvise'ing periodically
> with MADV_DONTNEED. If I understand correctly,
Charles Randall said:
>
> Out of 128M of ram, it's swapped nearly everything else out to keep 85M of
> this 400M file in ram, even though it will never touch it again. :)
>
> I see two possible fixes for this. One could be madvise'ing periodically
> with MADV_DONTNEED. If I understand correctly,
Arun Sharma said:
> "James E. Housley" writes:
>
> > Just for my infomation. What is the difference between "Inactive" and
> > "Free" memory. Right now top says I have 157M Inact and 3260K Free.
>
> Inactive means the page contains valid data belonging to some file,
> but is not mapped into an
>
> * We hack a fix to deal with the mmap/write case.
>
> A permanent vnode locking fix is many months away because core
> decided to ask Kirk to fix it, which was news to me at the time.
> However, I agree with the idea of having Kirk fix VNode locking.
>
> But since
>
> > Think of it like this: since alot of desktops sit in idle loops much
> > of the time, perhaps the Linux philosophy has been to improve such
> > behavior :-).
>
> The Linux philosophy already has better performance and will also get
> you much stronger TCP/IP user land copy performance unde
> "John S. Dyson" writes:
>
> > Finegrained locking either requires developers with IQ's of 200 or higher,
> > or a different kernel structure. I suggest that finegrained locking is
> > cool,
> > and can be intelligently used to mitigate (but n
Wes Peters said:
>
> Try a more meaningful benchmark, one that actually does something in
> the kernel before returning, and see how they do. Try calling kill
> or socket/close a few hundred thousand times and see how they do.
>
Historically, my emphasis on FreeBSD kernel work was to make it wor
Soren Schmidt said:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> It seems Christopher R. Bowman wrote:
> [exelent explanation snipped]
> > The alternative to the Giant Kernel Lock(tm) is so called fine grained
> > locking
> > wherein locking is pushed down closer to the data structure
Warner Losh said:
> In message <199906102125.oaa28...@mag.ucsd.edu> Bill Huey writes:
> : Yeah, that's problematic and short sighted on their part. It's certainly
> : not a question of expertise from what I've seen since there are very
> : competent technical folks with strong acedemic CS backgroun
>
> For what it's worth, and to throw another hat into the fray, it
> seems to me that two things are driving the tension here:
>
> 1)Matt is effectively in a position where he no longer has
> to work, and can now dedicate a significant amount of
> focussed effort over long interv
Dag-Erling Smorgrav said:
> Arun Sharma writes:
> > I'd say most of the differences are in implementation and development
> > methodology. Linux camp seems to be proud of breaking traditions and
> > concepts invented after lengthy research. I haven't seen that many
> > iconoclasts in my short enco
> John S. Dyson writes:
> > Howard Goldstein said:
> > > On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> wrote:
> > > : 4.0-CURRENT
> > >
> > > 3.2R too...
> > >
> > I just checked the source (CVS) tree, and some
> On Wed, 9 Jun 1999, John S. Dyson wrote:
>
> > Howard Goldstein said:
> > > On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> > > wrote:
> > > : On Mon, 7 Jun 1999, Matthew Dillon wrote:
> > > : > ... what version of the opera
Howard Goldstein said:
> On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
> wrote:
> : On Mon, 7 Jun 1999, Matthew Dillon wrote:
> : > ... what version of the operating system?
> : 4.0-CURRENT
>
> 3.2R too...
>
I just checked the source (CVS) tree, and something bad happend
between
Brian Feldman said:
> In the long-standing tradition of deadlocks, I present to you all a new one.
> This one locks in getblk, and causes other processes to lock in inode. It's
> easy to induce, but I have no idea how I'd go about fixing it myself
> (being very new to that part of the kernel.)
>
>
> One of the problems that would make it sensible to do a complete rewrite
> of vfs_bio.c is this?
>
Specifically for that reason, probably not. However, if the effort
was taken as an entire and encompassing effort, with the understanding
of what is really happening in the code regarding policy
Arun Sharma said:
> bread
> ffs_read
> ffs_getpages
> vnode_pager_getpages
> vm_fault
> ---
> slow_copyin
> ffs_write
> vn_write
> dofilewrite
> write
> syscall
>
> getblk finds that the buffer is marked B_BUSY and sleeps on it. But I
> can't figure out who marked it busy.
>
This looks l
> On Sat, 5 Jun 1999 03:24:07 -0500 (EST)
>
> > The frustration that I was showing was a result of off the wall assertions
> > being made, with few coherent questions. Your questions are often
> > analogous to someone saying that the VM code sucks, but will you help me
> > with it, by teachi
Matthew Dillon said:
>
> I don't want to be a pest, because this really shouldn't be on an
> open forum. But John: I would ask you questions and the answers I
> would get would be in the form: "Nobody understands that
> code but me, don't touch what you don't understand", or "T
Matthew Jacob said:
>
> In terms of design reviews and architecture *before* the commit, well, if
> you want to go that route I can assure you it's a major amount of work. It
> will bring FreeBSD into "adult" development- no large scale project with >
> 50 engineers really succeeds long term witho
>
> The problem was not that the original programmers were being ignored.
> It's that the original programmers found it difficult to express to a
> newcommer, the subtleties of what they had internalised years before.
>
> Both sides showed remarkable lack of patience.. Matt was in a hurry and
> J
> > I'm sure that the fact that -release ended up with such obvious
> > instabilities was out of your control (IMHO RELENG_3 shouldn't have
> > been dubbed -stable 'till 3.2 was tagged), but I'd bet that this did
>
> Just a side comment on this - there was tremendous flammage that the
> RELENG_
> >> IMO, revokation of commit privs has given enough time to support
> >> the learning curve and enforce a review process.
> >
> >I've been following this conversation with growing concern. It seems
> >to me there is a fairly simple solution to this problem: create a
> >branch for the ongoing VM
>
> Some sort of arrangement/understanding/procedure/whatever would need to be
> worked out to make sure that everybody involved understands everybody's
> angle so that we don't repeat it all over again. Maybe some of the
> groundwork can be done at usenix next week, but not all everybody will be
>
> And this nonsense in another email about things being untested is also
> complete bull. I had a machine dedicated to running test kernels 24 hours
> a day. I still do.
>
Testing on local machines isn't generally sufficient, due to the need for
running diverse applications in vari
> On Fri, 4 Jun 1999, Brian Somers wrote:
>
> > The system was becoming unstable due to Matts changes. Whether the
> > instabilities were in Matts code or somewhere else is irrelevent.
> > The reaction was (IMHO) the right thing to do.
>
> I think where the problem lied is very relevent.
>
>
> > It wasn't the "dark side" of core, it was the panic'ed and worried
> > part of core that was seeing things happening without careful review.
>
> The system was becoming unstable due to Matts changes. Whether the
> instabilities were in Matts code or somewhere else is irrelevent.
> The reac
Amancio Hasty said:
>
> Silly me , I was wondering what happen to you . I vote that your commit
> priviliges should not be taken away by the "Dark Side" of core and
> should be re-instated.
>
It wasn't the "dark side" of core, it was the panic'ed and worried
part of core that was seeing things hap
Nate Williams said:
>
> Case in point, John Dyson's comments explanation to the mailing list for
> many of his design decisions explained to even an uninformed person like
> me that some of the changes you've made were penalizing FreeBSD, not
> helping it in some cases.
>
BTW, my frustration was
Matthew Dillon said:
>
> Alan and I are working on it. We are testing a fix for pipe_read() now
> and I'm working on one for pipe_write(). The fixes basically involve
> holding the pipe's lock throughout all calculations and I/O ops except
> when the code needs to explicitly tsl
Matthew Dillon said:
>
> We are attempting to reproduce the problem with a smaller dataset, but
> if anyone is hot on the pipe code in the kernel and can give it a
> once-over
> we may be able to find the bug more quickly.
>
After a quick code inspection (and I really don't remember
33 matches
Mail list logo
