arallel build systems
> at the same time.
Then it does seem reasonable to ask that the new one is at least as fast
as the old one.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
___
kbuild-devel mailing list
On Fri, Dec 28, 2001 at 12:35:50PM +1100, Keith Owens wrote:
> On Thu, 27 Dec 2001 17:15:45 -0800,
> Larry McVoy <[EMAIL PROTECTED]> wrote:
> >[talking about kbuild 2.5 speed]
> >Then it does seem reasonable to ask that the new one is at least as fast
> >as the ol
On Fri, Dec 28, 2001 at 12:41:48PM +1100, Keith Owens wrote:
> On Thu, 27 Dec 2001 17:37:39 -0800,
> Larry McVoy <[EMAIL PROTECTED]> wrote:
> >A couple of questions:
> >
> >a) will 2.5 be as fast as the current system? Faster?
>
> At the moment kbuild 2.5 ra
uses mmap instead of building the db in brk() space?
We've got a small, fast one that you can have under any license you
like, GPL, LGPL, whatever. We use it all over the BK code.
--
---
Larry McVoy lm at bitmover.com
the BK license doesn't let you reuse code and this code is part
of BK that we broke out and licensed under the GPL. The point being
that if there is reusable code in BK, we're willing to let people use
it under whatever license they want. It would be nice if that actually
happened aft
val = mdbm_fetch_str(m, "key");
etc.
No sockets, no back and forth, runs at mmap speed.
If you tell me what the data looks like that needs to be in the DB, i.e.,
how to get it, I'll code you up the "server" side.
--
---
Larry
More numbers. I coded up a little program (included below) which
reads paths from stdin, lstats() them, and builds an MDBM of inode ->
pathname entries. I ran that 10 times on the 2.4 kernel, which had 8679
files matching *.[chSs]. I did a little tuning of page size and inital
DB size (reduces
ource. The very fact
that they are atoms and don't interact with each seems to scream that they
should be located next to, or in, the stuff with which they do interact.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
this a viable choice? I've heard nothing
since Kai posted this. Keith?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
some code. Maybe I'll
finally actually be useful to the kernel after all these years...
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
On Sat, Dec 29, 2001 at 08:24:37PM +1100, Anton Blanchard wrote:
> How large is your core db stuff? The thing I like about tdb is that it
> is very simple, only recently growing over 1024 lines.
14044736 32921 mdbm.c
--
---
Larry McVoy lm at bitmover.com
have a system which does more, is more accurate,
and is faster than the system we currently use. Right? Rock on.
Has anyone integrated the kbuild stuff into a BK tree, so I could pull
from it and play with it? If not, I might have a go at it and make
a bk://kbuild.bkbits.net project.
he same tree. It also makes it really easy to
"clean" a tree.
On the other hand, I do wonder whether ccache could be used to get the
same effect. Sam?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
13 matches
Mail list logo
