[darcs-users] darcs record and huge patches

Aggelos Economopoulos aoiko at cc.ece.ntua.gr
Thu Jan 29 00:58:34 UTC 2004

On Wed, 28 Jan 2004 12:20:51 -0500
David Roundy <droundy at jdj5.mit.edu> wrote:

> On Wed, Jan 28, 2004 at 06:04:48PM +0200, Aggelos Economopoulos wrote:
> > Any idea what these memory areas are for?
> > (this is from /proc/.../map; fields are: start, end, resident,
> > private resident, object, protection, reference count, shadow count,
> > flags, cow, needs cow, type. Type 'default' means MAP_ANON)
> > 
> > 0x81e4000 0xe637000 4212 0 0xd3d3d960 rwx 2 0 0x2184 NCOW NNC
> > default 0x2ab00000 0x36f00000 49965 0 0xd495b2a0 rwx 1 0 0x2184 NCOW
> > NNC default
> > 
> > most of the pages are resident, but I doubt darcs needs them all,
> > that's why I asked if there's any way to reclaim them.
> Hmmmm.  I've never looked at /proc/.../map, so I'm not sure what
> they'd be.  The mapped files may be files in _darcs/current/, which
> get mmapped so they can be compared with those in the working
> directory.  Other than that I have very little idea.

Sorry, I should clarify. The later area (vm object) is of type
OBJT_DEFAULT, which means it's been created with mmap(MAP_ANON) (the
former could be brk(2) space). If darcs didn't do the allocation (and
grep shows it doesn't know about MAP_ANON) it's probably from ghc (a
grep in ghc/rts/ returns a few matches but I haven't checked them).
DragonFly malloc() mostly uses brk(2) so it shouldn't be it. My question
was, why isn't that memory ever unmap()ed? (but now I think you've
answered my question in 'Re: Current Pull Attempting to Overallocate' -
I'm not so sure what the malloc() tricks get you though)

> > Yeah, small changesets take almost constant time, equal to the 'scan
> > the whole tree' overhead. If only I could let darcs record know
> > where to look. Consider this a feature request :)
> Hmmm.  Yeah, that's something that another friend has been asking for.
>  He
> figures that if you run darcs record --all in a subdirectory, only
> changes in that directory should be recorded, and that you should be
> able to run`darcs record foo.c bar.c` to record only changes to foo.c
> and bar.c.  I think it's a good idea.  I hadn't considered that it
> could be used to speed up automated calls (as in this case), but
> that's definitely an added bonus... I'll put it on my internal TODO
> list (since I'm at work now).

Thanks. Being able to pipe in the file list would be nice too.


More information about the darcs-users mailing list