make_dev(9) man page: inconsistent with reality
Dear colleagues, [EMAIL PROTECTED]:/FreeBSD/src.current> cvs -R stat share/man/man9/make_dev.9 === File: make_dev.9Status: Up-to-date Working revision:1.15Mon Nov 10 10:22:33 2003 Repository revision: 1.15/home/ncvs/src/share/man/man9/make_dev.9,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) This man page refers to old dev_t machanism instead of struct cdev *. The same inconsistency applies to RELENG_5. Unfortunately, I can't provide useful diff myself (not deep enough kernel structures understanding), but I suppose it should be fixed before 5.4-R. Thanks. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
relation between PQ_CACHESIZE and PQ_L2_SIZE
hi, all in vm_page.h PQ_CACHESIZE / PQ_L2_SIZE is always equal to 4. some think "4" represents a 4-way set associative, but I think "4" is the page size.Which is right? If I'm right, how bsd deal with 8KB page size? Best Regards Bao Zhao __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: contributing to fbsd
> If you're interested, I can send you a copy of the code... It's a bare > implementation with some basic regression tests performed It doesn't > layer ontop of kmem_cache though... Yes, John. Send me please. Thank you, Andriy. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
relation between PQ_CACHESIZE and PQ_L2_SIZE
hi,all in vm_page.h PQ_CACHESIZE/PQ_L2_SIZE is always equal to 4. what does "4 " mean? some think it is 4-way set associative,but I think it is the page's size-4KB. If I'm right, How BSD deals with 8KB page size? Best Regards Bao Zhao __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make_dev(9) man page: inconsistent with reality
On Sat, Mar 26, 2005 at 06:21:21PM +0300, Dmitry Morozovsky wrote: > Dear colleagues, > > [EMAIL PROTECTED]:/FreeBSD/src.current> cvs -R stat share/man/man9/make_dev.9 > === > File: make_dev.9Status: Up-to-date > >Working revision:1.15Mon Nov 10 10:22:33 2003 >Repository revision: 1.15/home/ncvs/src/share/man/man9/make_dev.9,v >Sticky Tag: (none) >Sticky Date: (none) >Sticky Options: (none) > > This man page refers to old dev_t machanism instead of struct cdev *. The > same > inconsistency applies to RELENG_5. > > Unfortunately, I can't provide useful diff myself (not deep enough kernel > structures understanding), but I suppose it should be fixed before 5.4-R. > There's a doc PR about this which I haven't committed yet. I'll take a look at this later. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpkJTY58pzCe.pgp Description: PGP signature
Re: contributing to fbsd
(exept patching [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) in wich anyone doesn't interesting as it appeared )) PRs can get lost or misfiled... it's just human nature. threads PRs are broadcasted every moth AFAIN ) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: contributing to fbsd
On Sat, Mar 26, 2005 at 04:32:56PM -0500, Mark W. Krentel wrote: > > The VM map algorithms are the same as ever, though. They use linear > > traversal along with a cached reference to the last lookup. There > > are certainly some workloads that should benefit from this, so it > > definitely could be something you could work on. > > Not any more. The first_free hint was replaced by an O(log n) > algorithm built into the splay tree back in August 2004. See > rev. 1.357 of vm_map.c. Cool, I don't think I noticed that happen. That would be for 5.x and 6.x both, then, too. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: relation between PQ_CACHESIZE and PQ_L2_SIZE
On Sat, Mar 26, 2005 at 09:44:36AM -0800, Bao Zhao wrote: > some think it is 4-way set associative,but I think it > is the page's size-4KB. > > If I'm right, How BSD deals with 8KB page size? Please search this list's archives as there's a thread on this from a few years back (I was one of the protagonists). BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: relation between PQ_CACHESIZE and PQ_L2_SIZE
--- Bruce M Simpson <[EMAIL PROTECTED]> wrote: > On Sat, Mar 26, 2005 at 09:44:36AM -0800, Bao Zhao > wrote: > > some think it is 4-way set associative,but I think > it > > is the page's size-4KB. > > > > If I'm right, How BSD deals with 8KB page size? > > Please search this list's archives as there's a > thread on this from a > few years back (I was one of the protagonists). > > BMS > Yes, I have searched the archives before I asked the question.see below: http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2003-June/001655.html But what puzzled me is : why not page size is a factor when calculating the number of colors? Best Regard Bao Zhao __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: relation between PQ_CACHESIZE and PQ_L2_SIZE
> http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2003-June/001655.html >But what puzzled me is : why not page size is a > factor when calculating the number of colors? Page coloring in freebsd was implemented by John Dyson. It is needed to better utilize the cache. Depending on cache's implementation fully-associative vs. 4-way vs 2-way etc you might have problems. A subset of bits (low-bits) from the page frame's (physical) address tells us where can data be stored in processor cache. We want a relatively equal distribution of these "colors" so that we utilize as much of cache real estate as possible. Hence, we are interested in the size of a set, not size of a page. I am sure, there are whole bunch of articles written about this. I could give you some pointers offline. Igor. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: axe CPU_UPGRADE_HW_CACHE from i386 specific code
In message: <[EMAIL PROTECTED]>
Mark Santcroos <[EMAIL PROTECTED]> writes:
: It looks like CPU_UPGRADE_HW_CACHE is only used in PC98, so it can be
: removed from all I386 specific code.
:
: Any objections to the following patch?
This does appear to be a pc98 only item. A grep of the tree shows
this to be the clase.
However, there's more opportunity here for cleanup. One can easily
move nearly all the PC98 code out of initcpu.
First, there's some redudant code:
In initcput.c we see:
static void
init_bluelightning(void)
{
u_long eflags;
#if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE)
need_post_dma_flush = 1;
#endif
...
but we also see:
#if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE)
...
} else if (strcmp(cpu_vendor, "IBM") == 0) {
need_post_dma_flush = 1;
...
#endif
So, we set it once in init_bluelightning, and again at the tail end of
initialize cpu. So that code should be just eliminated, unless I've
missed something subtle in my analysis of the code.
In addition, one can easily add the CPU_I486_ON_386 tests to the same
code at the end of initializecpu(). In fact, it may already be there,
or there may be a bug:
#ifdef CPU_I486_ON_386
case CPU_486:
init_i486_on_386();
break;
#endif
vs
case CPU_CY486DX:
need_pre_dma_flush = 1;
#ifdef CPU_I486_ON_386
need_post_dma_flush = 1;
#endif
break;
Note that the comments say that this flushing is necessary for
non-intel hardware only, yet CPU_486 is a true intel part. At the
very least, the ifdef code in init_i486_on_386 can be eliminated,
since it appears redudant with code later on:
} else {
#ifdef CPU_I486_ON_386
need_pre_dma_flush = 1;
#endif
This makes the code fairly well contained, and it could be convered to
a function an placed somehere appropriate in pc98/pc98, maybe
pc98_machine.c? This would localize the use of the
need_{pre,post}_dma_flush variables to pc98/pc98 (well, and one
instance in dev/ct, which doesn't call the standard DMA complete
routines, but I've not investigated further). This would shrink the
size of the ifdefs down to a single one-liner...
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
