I'm trying to debug a KLD in -stable and I can't get gdb to show me a
stack trace with the extra info (variable names, line numbers etc..)
I've built a debugging kernel and copied it to the debug machine and I
can connect to the machine to be debugged OK, but none of the back
traces have the extr
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
> Do a web search. It's basically a way to have a linked list that
> you can do nearly a binary search on, however it costs several
> additional linkages. It was also the "pool on the roof" trick
> we'd do to the new guy at clickarray.
Hm, did you g
* Mike Silbersack <[EMAIL PROTECTED]> [020307 22:35] wrote:
>
> On Thu, 7 Mar 2002, Alfred Perlstein wrote:
>
> > * Terry Lambert <[EMAIL PROTECTED]> [020307 22:24] wrote:
> > >
> > > If it were just the pcbhash, I think I'd go with a btree...
> > > or to make Alfred happy... a skiplist... ;^).
On Thu, 7 Mar 2002 11:12:03 -0800 (PST)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Hmm. well, I don't think this test is very meaningful. If the
> machines have 256M of ram and the test is doing a two-swipe access of
> 256M of VM. This doesn't represent any real test and I would no
On Thu, 07 Mar 2002 11:19:25 -0800
Terry Lambert <[EMAIL PROTECTED]> wrote:
> > #include
> > #include
> > #include
> >
> > #define MALLOC_SIZE 1024*1024*256
> >
> > int main(int argc, char **argv) {
> >char *ptr;
> >int i, i_count;
> >int j;
> >
> >ptr = (char *) malloc(MALL
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
> * Terry Lambert <[EMAIL PROTECTED]> [020307 22:24] wrote:
> >
> > If it were just the pcbhash, I think I'd go with a btree...
> > or to make Alfred happy... a skiplist... ;^).
>
> Argh, someone hand me the firehose, Terry seems really thirsty...
>
>
On Thu, 7 Mar 2002 10:42:05 -0800
"David O'Brien" <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > > I've tested it with :
> > >
> > > cc -O6 -o malloc_test malloc_test.c
> >
> > That -O6 does not look right from here. Do we support anything over
> > -
On Thu, 7 Mar 2002 11:41:28 + (GMT)
Mike Silbersack <[EMAIL PROTECTED]> wrote:
>
> On Thu, 7 Mar 2002, cjp wrote:
>
> > In order to handle the kruft that occurs, there is the out of memory
> > killer, oom_killer.
> > Which merrily goes through the list of processes, killing off the low
> >
* Terry Lambert <[EMAIL PROTECTED]> [020307 22:24] wrote:
>
> If it were just the pcbhash, I think I'd go with a btree...
> or to make Alfred happy... a skiplist... ;^).
Argh, someone hand me the firehose, Terry seems really thirsty...
--
-Alfred Perlstein [[EMAIL PROTECTED]]
To Unsubscribe:
Bill Fumerola wrote:
> i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene.
ip_fw_chk should be obscene and not heard? 8-).
> we're talking about an optimization that less then .1% of our userbase
> will ever take advantage of v. a pessimization (additional argument in
> the
Bill Fumerola wrote:
> On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote:
> > what would be even nicer is if ipfw found the cached entry and passed it
> > back to ip_input so it didn't need to :-)
>
> i think this entire idea of cacheing it in ip_input() is a bad idea, no
> offense
On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote:
> A couple of comments:
>
> - You can always cache the pcb the first time it's used, and then have it
> available for future use. I agree with your concerns about generating
> it every time -- that would be a disaster for routers
A couple of comments:
- You can always cache the pcb the first time it's used, and then have it
available for future use. I agree with your concerns about generating
it every time -- that would be a disaster for routers where no packets
are even delivered locally. :-)
- The uid/gid code
On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote:
> what would be even nicer is if ipfw found the cached entry and passed it
> back to ip_input so it didn't need to :-)
i think this entire idea of cacheing it in ip_input() is a bad idea, no
offense terry.
first, having a uid or g
On Thu, Mar 07, 2002 at 03:29:44PM -0800, David Boggs wrote:
> Attached below is some BPF code. As I read it, bpfattach() is passed
> an ifp (struct ifnet *). It mallocs a 'bpf_if' (1) and installs the ifp
> in it (2). Then it uses this pointer to ZERO a pointer in the ifp named
> if_bpf (3) (p
[reposted from FreeBSD-questions]
I'm writing a network device driver. I'm using FreeBSD 4.4-RELEASE.
I can't get BPF to work; it dereferences a nil pointer.
Attached below is some BPF code. As I read it, bpfattach() is passed
an ifp (struct ifnet *). It mallocs a 'bpf_if' (1) and installs th
In message: <009c01c1c356$93e13be0$c80ca8c0@khromovv>
"Valery N. Khromov" <[EMAIL PROTECTED]> writes:
: I'd like to develop a kernel module for FreeBSD, able to read & write
: directly to VGA text-mode screen buffer. I know that this buffer is located
: at 0xB8000 in physical address s
Michael Smith wrote:
> > The only place this is referred to as a "stack" at all is in
> > one comment in the libstand.3 man page, which hardly excuses
> > you ripping me a new one.
>
> So because I called it a "stack" I *must* have been referring to the
> kernel, not actually the loader (since th
Miguel Mendez <[EMAIL PROTECTED]> types:
> On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote:
> > That is true. C++ is as ugly as C, but has all the problems of Object
> > Orient Languages.
> What are you smoking? :-) No language in this world fits OS development
> better than C. IMHO is
>Another point that I should bring up in regards to swap performance:
>systems that require good swap performance will almost always have
>more then one physical disk to swap to. FreeBSD is very good at
>paging to swap with a single disk, but it kicks ass paging to swap
>with
In a message written on Thu, Mar 07, 2002 at 03:27:49PM -0500, Garance A Drosihn wrote:
> As to the wording, PHK suggested that the wording for this
> rule in style(9) be changed:
> - - -
> get rid of the word boolean, ie: change
> Do not use ! for tests unless it is a boolean, e.g. use
> to
At 2:16 AM -0500 3/7/02, Brian T.Schellenberger wrote:
>Maybe your brain has gotten used to it, but to us ordinary
>mortals, even us ordinary mortals who've been slogging C
>code for time periods that can be measured in decades
>(yikes!), it is very tempting to read
>
> if (!strcmp(a,b,l))
>
>as
On Thu, Feb 28, 2002 at 01:26:49AM -0500, Clark C . Evans wrote:
| | http://people.freebsd.org/~bsd/cdroot/
|
| Ok. I've tried this route and it seems to be working,
| thank you all so much for your help and pointers.
Thus far, cdroot has worked well for me. I have a PleXwriter
23/10/40A and a
> Michael Smith wrote:
> > Should you care to be informed rather than playing from the sidelines,
> > see the primitive 'stacking' used to implement transparent gzipped file
> > support in libstand.
>
> The only place this is referred to as a "stack" at all is in
> one comment in the libstand.3 m
Michael Smith wrote:
> Should you care to be informed rather than playing from the sidelines,
> see the primitive 'stacking' used to implement transparent gzipped file
> support in libstand.
The only place this is referred to as a "stack" at all is in
one comment in the libstand.3 man page, which
Simon 'corecode' Schubert wrote:
> > Are you using NAT?
>
> yep.
>
> > The libalias incremental checksum calculation is incorrect;
> > it assumes that a two's complement network order underflow
> > will result in the same value as a one's complement host
> > order underflow. This results in off
> Michael Smith wrote:
> > > > > I don't like this. I would much rather see support for 'split' files
> > > > > implemented as a stacking filesystem layer like the gzip support, wit
> h
> > > > > the simple recognition of 'foo.gz.aa' as the first part of a split
> > > > > version of 'foo.gz', whi
Matthew Dillon wrote:
> :The bzero is unnecessary on FreeBSD. Allocated pages start out
> :zero'ed. Part of the performance issue might be that FreeBSD is
> :being asked to zero the pages twice, instead of once.
>
> malloc() does not guarentee a zero'd page, even though the
> side effec
On Thu, 07 Mar 2002 10:49:22 -0800 Terry Lambert <[EMAIL PROTECTED]> wrote:
> Simon 'corecode' Schubert wrote:
> > to everybody who doesn't believe that: it really generates bad code.
> > i've been having severe problems with my tcp and udp stack lately (on a
> > i586/mmx machine). guess what, -O
:>ptr = (char *) malloc(MALLOC_SIZE);
:>bzero(ptr, MALLOC_SIZE);
:
:The bzero is unnecessary on FreeBSD. Allocated pages start out
:zero'ed. Part of the performance issue might be that FreeBSD is
:being asked to zero the pages twice, instead of once.
malloc() does not guarentee a z
Michael Smith wrote:
> > > > I don't like this. I would much rather see support for 'split' files
> > > > implemented as a stacking filesystem layer like the gzip support, with
> > > > the simple recognition of 'foo.gz.aa' as the first part of a split
> > > > version of 'foo.gz', which in turn is
:which one does the data come from?
:
:On Thu, 7 Mar 2002, Zhihui Zhang wrote:
:
:>
:> Is there any fundamental reason why a page can not be owned by more than
:> one VM object? If that was the case, the bogus page stuff in vfs_bio.c
:> could be made cleaner IMHO.
:>
:> -Zhihui
:>
I thin
> #include
> #include
> #include
>
> #define MALLOC_SIZE 1024*1024*256
>
> int main(int argc, char **argv) {
>char *ptr;
>int i, i_count;
>int j;
>
>ptr = (char *) malloc(MALLOC_SIZE);
>bzero(ptr, MALLOC_SIZE);
The bzero is unnecessary on FreeBSD. Allocated pages start
The bogus page is owned by the system object, not by individual objects
associated with the files. If a page could be owned by more than one
objects, then we could let the object associated with a file to own the
bogus page.
-Zhihui
On Thu, 7 Mar 2002, Julian Elischer wrote:
> which one does t
Hmm. well, I don't think this test is very meaningful. If the machines
have 256M of ram and the test is doing a two-swipe access of 256M of VM.
This doesn't represent any real test and I would not be surprised by
the difference in timing.
It all comes down to how much real
which one does the data come from?
On Thu, 7 Mar 2002, Zhihui Zhang wrote:
>
> Is there any fundamental reason why a page can not be owned by more than
> one VM object? If that was the case, the bogus page stuff in vfs_bio.c
> could be made cleaner IMHO.
>
> -Zhihui
>
>
> To Unsubscribe: se
:...
:> > This is a comparison of how fast Linux can do something
:> > STUPID versus how fast a real OS can do something intelligently. Your
:> > test is giving you misleading, and dangerous numbers. Do not go waving
:> > them around until you have actually looked at mallocs behavior on the
:>
> I'd like to develop a kernel module for FreeBSD, able to read & write
> directly to VGA text-mode screen buffer. I know that this buffer is located
> at 0xB8000 in physical address space. But in kernel I must address it using
> kernel virtual address space.
>
> Thus, the question is: how can I
Zhihui Zhang wrote:
> Is there any fundamental reason why a page can not be owned by more than
> one VM object? If that was the case, the bogus page stuff in vfs_bio.c
> could be made cleaner IMHO.
When you need to reclaim the page, you would have to identify
all owners, rather than a single own
On Thu, Mar 07, 2002 at 11:41:28AM +, Mike Silbersack wrote:
> In any case, we can't make any useful comparisons until Dimitar posts the
> source to his test program.
>
> Dimitar, post the source for the test program!
Does your MTA strip attachments?
-> I 1 [text/plain
Simon 'corecode' Schubert wrote:
> to everybody who doesn't believe that: it really generates bad code.
> i've been having severe problems with my tcp and udp stack lately (on a
> i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<<
> generated bad tcp and/or udp checksums (depe
> > > I don't like this. I would much rather see support for 'split' files
> > > implemented as a stacking filesystem layer like the gzip support, with
> > > the simple recognition of 'foo.gz.aa' as the first part of a split
> > > version of 'foo.gz', which in turn is recognised as a compressed v
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > I've tested it with :
> >
> > cc -O6 -o malloc_test malloc_test.c
>
> That -O6 does not look right from here. Do we support anything over -O2?
>
> And how about some source for malloc_test.c? The fact of running
> something at -O6
On Thu, 7 Mar 2002, Rogier R. Mulhuijzen wrote:
>
> >Once Dimitar posts his test program, we'll be able to generate a more
> >clear picture about what's really happening. Until then, please control
> >the ranting.
>
> Am I the only one who saw that he attached it to his 1st mail?
Apparently no
Julian Elischer wrote:
> what would be even nicer is if ipfw found the cached entry and passed it
> back to ip_input so it didn't need to :-)
This is the approach I intended.
The problem is that there are cases where you want the inpcb
for additional processing (e.g. ipfw), and cases where ther
> > At any rate, my key point is that the splitting should be invisible, and
> > *definitely* not pushed up into the loader.
>
> Ok, sounds reasonably. I'll try to reimplement the feature this way.
>
> Thank you for suggestion.
Thanks for doing the real work!
= Mike
--
To announce that ther
>Once Dimitar posts his test program, we'll be able to generate a more
>clear picture about what's really happening. Until then, please control
>the ranting.
Am I the only one who saw that he attached it to his 1st mail?
Here you go:
#include
#include
#include
#define MALLOC_SIZE 1024*102
On Thu, 7 Mar 2002, Tom wrote:
> But when you lose that data, do you not get burnt by that same situation?
> I have written a 1GB file to a linux box, and then within 5 seconds of it
> finishing, yanked the power cord. When I booted it back up, the file was
> *JUST NOT THERE*, I tried it a few o
> > This is a comparison of how fast Linux can do something
> > STUPID versus how fast a real OS can do something intelligently. Your
> > test is giving you misleading, and dangerous numbers. Do not go waving
> > them around until you have actually looked at mallocs behavior on the
> > different
Maxim Sobolev wrote:
> Michael Smith wrote:
> > > Please review attached patch, which adds long overdue feature to our
> > > loader(8), allowing it to load sequence of files as a single object.
> >
> > I don't like this. I would much rather see support for 'split' files
> > implemented as a stac
On Thu, 7 Mar 2002, cjp wrote:
> In order to handle the kruft that occurs, there is the out of memory killer,
> oom_killer.
> Which merrily goes through the list of processes, killing off the low priority
> processes
> until enough memory is free to satisfy what was most recently used. It's the
The mapping between data objects (one-to-one or one-to-many) seem to be
the most troublesome stuff to deal with when introducing new data
structures. But if there is never the need to lookup an object from a
page, then maybe we can use a linkage structure like this:
struct vm_page_linka
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
> * Jan Grant <[EMAIL PROTECTED]> [020307 08:12] wrote:
> > Something odd seems to be happening; I'd appreciate "look here"
> > suggestions. I suspect mmapped pages aren't being flushed but gawd alone
> > knows why.
> >
> > Situation: vmware2, with a "f
* Zhihui Zhang <[EMAIL PROTECTED]> [020307 08:28] wrote:
>
> Is there any fundamental reason why a page can not be owned by more than
> one VM object? If that was the case, the bogus page stuff in vfs_bio.c
> could be made cleaner IMHO.
There is only enough linkage in the vm page to support it
* Jan Grant <[EMAIL PROTECTED]> [020307 08:12] wrote:
> Something odd seems to be happening; I'd appreciate "look here"
> suggestions. I suspect mmapped pages aren't being flushed but gawd alone
> knows why.
>
> Situation: vmware2, with a "fake disk", files in the /external FS
> (/external/vmware
Is there any fundamental reason why a page can not be owned by more than
one VM object? If that was the case, the bogus page stuff in vfs_bio.c
could be made cleaner IMHO.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Something odd seems to be happening; I'd appreciate "look here"
suggestions. I suspect mmapped pages aren't being flushed but gawd alone
knows why.
Situation: vmware2, with a "fake disk", files in the /external FS
(/external/vmware1/nt1.*).
FBSD-stable. Behaviour's been like this for quite some
On Thu, 7 Mar 2002 16:36:15 +0100 Erik Trulsson <[EMAIL PROTECTED]> wrote:
> > > > I've tested it with :
> > > >
> > > > cc -O6 -o malloc_test malloc_test.c
> > >
> > > That -O6 does not look right from here. Do we support anything over -O2?
> >
> > ISTR that -On is exactly the same for -O2 f
On Thu, Mar 07, 2002 at 04:47:24PM +0200, Peter Pentchev wrote:
> On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> > On Thu, 7 Mar 2002 14:27:59 +0200
> > Dimitar Peikov <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > > Julian Elischer <[EMAIL PROTECTED
On Thu, Mar 07, 2002 at 09:42:44AM -0500, cjp wrote:
> This is a comparison of how fast Linux can do something
> STUPID versus how fast a real OS can do something intelligently. Your
> test is giving you misleading, and dangerous numbers. Do not go waving them
> around until you have actually lo
On Thu, 7 Mar 2002 09:42:44 -0500
"cjp" <[EMAIL PROTECTED]> wrote:
> This is a comparison of how fast Linux can do something
> STUPID versus how fast a real OS can do something intelligently. Your
> test is giving you misleading, and dangerous numbers. Do not go waving
> them around until you h
On Thu, 7 Mar 2002, cjp wrote:
You are probably misinformed, because FreeBSD also does overcommit of
memory. If you look up the mail archives you will find long battles about
the pros and cons of this.
harti
c>This is a comparison of how fast Linux can do something
c>STUPID versus how fast a re
This is a comparison of how fast Linux can do something
STUPID versus how fast a real OS can do something intelligently. Your
test is giving you misleading, and dangerous numbers. Do not go waving them
around until you have actually looked at mallocs behavior on the different
systems.
Here's wh
On Thu, 7 Mar 2002 08:09:06 -0600
GB Clark <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Mar 2002 14:27:59 +0200
> Dimitar Peikov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > Julian Elischer <[EMAIL PROTECTED]> wrote:
> >
> > > he said -stable..
> > >
> > > what are th
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
> On Thu, 7 Mar 2002 14:27:59 +0200
> Dimitar Peikov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> > Julian Elischer <[EMAIL PROTECTED]> wrote:
> >
> > > he said -stable..
> > >
> > > what are the malloc opti
On Tue, 5 Mar 2002, Mark Murray wrote:
> > We did make some enhancements that serve our needs, but may not be
> > best for everyone. We actually need entropy in quantity since we could be
> > doing a lot of crypto operations back to back and it can easily become our
> > worst bottleneck.
>
>
On Thu, 7 Mar 2002 14:27:59 +0200
Dimitar Peikov <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
> Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> > he said -stable..
> >
> > what are the malloc options on -stable?
> >
> > maybe we should make sure that they are null
> >
[This is probably -chat material ...]
On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote:
> That is true. C++ is as ugly as C, but has all the problems of Object
> Orient Languages.
I love this quote (from http://www.paulgraham.com/noop.html):
Object-oriented programming generates a
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer <[EMAIL PROTECTED]> wrote:
> he said -stable..
>
> what are the malloc options on -stable?
>
> maybe we should make sure that they are null
>
> ln -s ">" /etc/malloc.conf
> (I hope that helps) :)
>
I've tested it with :
cc -O6 -o mall
Ok :-)
I am caught. I hit the send key by accident when I realized I had misread
the question.
> Andy, what were you trying to say?
>
> Or is that the way the Linux kernel converts addresses?
>
Probably! :-)
Have you a name yet for 'fish?'
Andy
To Unsubscribe: send mail to [EMAIL PROT
he said -stable..
what are the malloc options on -stable?
maybe we should make sure that they are null
ln -s ">" /etc/malloc.conf
(I hope that helps) :)
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
> * Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> > I start some performance test
On Thu, Mar 07, 2002 at 01:09:40PM +0100, Andy Sporner wrote:
Andy, what were you trying to say?
Or is that the way the Linux kernel converts addresses?
Cheers,
--
Miguel Mendez - [EMAIL PROTECTED]
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ
Michael Smith wrote:
>
> > > > Please review attached patch, which adds long overdue feature to our
> > > > loader(8), allowing it to load sequence of files as a single object.
> > >
> > > I don't like this. I would much rather see support for 'split' files
> > > implemented as a stacking files
On 04-Mar-02 Valery N. Khromov wrote:
> I'd like to develop a kernel module for FreeBSD, able to read & write
> directly to VGA text-mode screen buffer. I know that this buffer is located
> at 0xB8000 in physical address space. But in kernel I must address it using
> kernel virtual address space.
what would be even nicer is if ipfw found the cached entry and passed it
back to ip_input so it didn't need to :-)
On Thu, 7 Mar 2002, Bill Fumerola wrote:
> On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote:
>
> > There are redundant calls to the in_pcblookup_hash() in the
> > ip_
I'd like to develop a kernel module for FreeBSD, able to read & write
directly to VGA text-mode screen buffer. I know that this buffer is located
at 0xB8000 in physical address space. But in kernel I must address it using
kernel virtual address space.
Thus, the question is: how can I _correctly_
On Mar 06, at 11:39 PM, Mike Meyer wrote:
>
> D J Hawkey Jr <[EMAIL PROTECTED]> types:
> > First, you're ascribing me to a group I don't belong. While I don't know
> > Eiffel, or Lisp, or Modula, Snobol, etc., I don't demean them, nor do I
> > bitch about such-and-such being written with them (we
On Wed, 6 Mar 2002, David O'Brien wrote:
> Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T
> C. Got it?
I thought it was, because you can't write an event loop without using
(infinite) recursion :-)
jan
PS. This is all very amusing.
--
jan grant, ILRT, University of
> > > Please review attached patch, which adds long overdue feature to our
> > > loader(8), allowing it to load sequence of files as a single object.
> >
> > I don't like this. I would much rather see support for 'split' files
> > implemented as a stacking filesystem layer like the gzip support
On Thursday 07 March 2002 12:59 am, Poul-Henning Kamp wrote:
| In message <[EMAIL PROTECTED]>, "David O'Brien" writes:
| >Implies??? I thought I was quite explicit:
| >
| >to prevent is "if (!strcmp(a,b))" which when read is extremely wrong
| > of that is actually happening.
| >
| >! is prono
On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote:
> There are redundant calls to the in_pcblookup_hash() in the
> ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the
> ip_input path.
in addition to what you're talking about, ipfw will repeat the hash
lookup for every rule it g
Michael Smith wrote:
>
> > Please review attached patch, which adds long overdue feature to our
> > loader(8), allowing it to load sequence of files as a single object.
>
> I don't like this. I would much rather see support for 'split' files
> implemented as a stacking filesystem layer like th
* Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
> don't comment about 'bzero' performance, but when RAM is over, Linux
> is much faster. I have no idea what is the algorithm of swapping but it seems that
>the granu
> Please review attached patch, which adds long overdue feature to our
> loader(8), allowing it to load sequence of files as a single object.
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like the gzip support, with
the simple
On Thu, 7 Mar 2002, Dimitar Peikov wrote:
> I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
> don't comment about 'bzero' performance, but when RAM is over, Linux
> is much faster. I have no idea what is the algorithm of swapping but it seems that
>the granularity of swapp
On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote:
> That is true. C++ is as ugly as C, but has all the problems of Object
> Orient Languages.
What are you smoking? :-) No language in this world fits OS development
better than C. IMHO is one of the most beautiful languages ever created.
* Dimitar Peikov <[EMAIL PROTECTED]> [020307 00:45] wrote:
> I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
> don't comment about 'bzero' performance, but when RAM is over, Linux
> is much faster. I have no idea what is the algorithm of swapping but it seems that
>the granu
I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
don't comment about 'bzero' performance, but when RAM is over, Linux
is much faster. I have no idea what is the algorithm of swapping but it seems that the
granularity of swapping pieces is the key or the importance of swapping
88 matches
Mail list logo
