review: patch to restore VLAN kernel API in RELENG_6

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE

? sys/dev/bge/if_bge.cbak
? sys/dev/em/if_em.cbak
? sys/dev/ixgb/if_ixgb.cbak
? sys/dev/nge/if_nge.cbak
? sys/dev/re/if_re.cbak
? sys/dev/txp/if_txp.cbak
? sys/dev/vge/if_vge.cbak
? sys/net80211/ieee80211_input.cbak
Index: sys/dev/bge/if_bge.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.7
diff -u -r1.91.2.7 if_bge.c
--- sys/dev/bge/if_bge.c	13 Jan 2006 11:51:08 -0000	1.91.2.7
+++ sys/dev/bge/if_bge.c	13 Jan 2006 17:04:31 -0000
 <at>  <at>  -2862,7 +2862,7  <at>  <at> 
 		 * attach that information to the packet.
 		 */
 		if (have_tag) {
-			VLAN_INPUT_TAG(ifp, m, vlan_tag);
+			VLAN_INPUT_TAG_NEW(ifp, m, vlan_tag);
 			if (m == NULL)
 				continue;
 		}
Index: sys/dev/em/if_em.c

Re: review: patch to restore VLAN kernel API in RELENG_6

Hi, Gleb,

On Fri, Jan 13, 2006 at 08:05:52PM +0300, Gleb Smirnoff wrote:

> Index: sys/dev/bge/if_bge.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
> retrieving revision 1.91.2.7
> diff -u -r1.91.2.7 if_bge.c
> --- sys/dev/bge/if_bge.c	13 Jan 2006 11:51:08 -0000	1.91.2.7
> +++ sys/dev/bge/if_bge.c	13 Jan 2006 17:04:31 -0000
>  <at>  <at>  -2862,7 +2862,7  <at>  <at> 
>  		 * attach that information to the packet.
>  		 */
>  		if (have_tag) {
> -			VLAN_INPUT_TAG(ifp, m, vlan_tag);
> +			VLAN_INPUT_TAG_NEW(ifp, m, vlan_tag);

What if "VLAN_INPUT_TAG_2" or something with numerical name?

Just my $0.02, though 

Cheers,
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Re: review: patch to restore VLAN kernel API in RELENG_6

On Fri, Jan 13, 2006 at 05:17:59PM +0000, Xin LI wrote:
X> Hi, Gleb,
X> > ===================================================================
X> > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
X> > retrieving revision 1.91.2.7
X> > diff -u -r1.91.2.7 if_bge.c
X> > --- sys/dev/bge/if_bge.c	13 Jan 2006 11:51:08 -0000	1.91.2.7
X> > +++ sys/dev/bge/if_bge.c	13 Jan 2006 17:04:31 -0000
X> >  <at>  <at>  -2862,7 +2862,7  <at>  <at> 
X> >  		 * attach that information to the packet.
X> >  		 */
X> >  		if (have_tag) {
X> > -			VLAN_INPUT_TAG(ifp, m, vlan_tag);
X> > +			VLAN_INPUT_TAG_NEW(ifp, m, vlan_tag);
X> 
X> What if "VLAN_INPUT_TAG_2" or something with numerical name?
X> 
X> Just my $0.02, though 

I really don't care. :)

--

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Re: review: patch to restore VLAN kernel API in RELENG_6

On Fri, Jan 13, 2006 at 08:20:49PM +0300, Gleb Smirnoff wrote:
> On Fri, Jan 13, 2006 at 05:17:59PM +0000, Xin LI wrote:
> X> > +++ sys/dev/bge/if_bge.c	13 Jan 2006 17:04:31 -0000
> X> >  <at>  <at>  -2862,7 +2862,7  <at>  <at> 
> X> >  		 * attach that information to the packet.
> X> >  		 */
> X> >  		if (have_tag) {
> X> > -			VLAN_INPUT_TAG(ifp, m, vlan_tag);
> X> > +			VLAN_INPUT_TAG_NEW(ifp, m, vlan_tag);
> X> 
> X> What if "VLAN_INPUT_TAG_2" or something with numerical name?
> X> 
> X> Just my $0.02, though 
> 
> I really don't care. :)

Heh, my point was to make it possible to use the same name in
both drivers on RELENG_6 and 7.0, without having to call future
macros "foo_NEW_NG" or so =-)  Not really sure whether it is
conform to our tradition naming, though...

Cheers,
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Re: review: patch to restore VLAN kernel API in RELENG_6

On Fri, Jan 13, 2006 at 05:52:12PM +0000, Xin LI wrote:
X> On Fri, Jan 13, 2006 at 08:20:49PM +0300, Gleb Smirnoff wrote:
X> > On Fri, Jan 13, 2006 at 05:17:59PM +0000, Xin LI wrote:
X> > X> > +++ sys/dev/bge/if_bge.c	13 Jan 2006 17:04:31 -0000
X> > X> >  <at>  <at>  -2862,7 +2862,7  <at>  <at> 
X> > X> >  		 * attach that information to the packet.
X> > X> >  		 */
X> > X> >  		if (have_tag) {
X> > X> > -			VLAN_INPUT_TAG(ifp, m, vlan_tag);
X> > X> > +			VLAN_INPUT_TAG_NEW(ifp, m, vlan_tag);
X> > X> 
X> > X> What if "VLAN_INPUT_TAG_2" or something with numerical name?
X> > X> 
X> > X> Just my $0.02, though 
X> > 
X> > I really don't care. :)
X> 
X> Heh, my point was to make it possible to use the same name in
X> both drivers on RELENG_6 and 7.0, without having to call future
X> macros "foo_NEW_NG" or so =-)  Not really sure whether it is
X> conform to our tradition naming, though...

The correct macro takes 3 arguments, and the old one took 4. So
we can't make a code compilable with correct macro on both systems
without breaking API - using same macro.

--

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________

[RFC/Benchmarks] Per-CPU freelists

Hello,

I implemented per-CPU page freelists this weekend, in the hopes that it 
would improve  performance on SMP machines, as it should save a spinlock 
acquisition in vm_page_alloc(), in most cases (except when 
VM_ALLOC_INTERRUPT is set, and when the current cpu's free list is 
empty), and reduce contention. However, I was only able to test it on 
machine with two CPUs, where it didn't seem to make any difference.

You can set the number of pages that get added to the freelists each 
time it gets refilled in vm.pcpu.refill_num, and the maximum length of 
the freelists in vm.pcpu.max_len. Some stats are viewable in vm.pcpu.stats.

The patch is available at 
http://people.freebsd.org/~ssouhlal/testing/pcpu-freelists-20060115.diff

I would really appreciate if someone could benchmark/test this on a 
machine with more processors.

Here's the output of ministat(1) for buildkernel:
x refill_num=32, max_len=64
+ refill_num=4, max_len=-1 (effectively disabling the percpu freelists)
+--------------------------------------------------------------------------+
|+         +           x  x+ x                       +       +  x         x|
|    |_____________|_______M_MA____________A____________|__________|       |
+--------------------------------------------------------------------------+
     N           Min           Max        Median           Avg        Stddev
x   5        171.64        172.09        171.69       171.816    0.21220273
+   5        171.44        171.97        171.67       171.702    0.22928149
No difference proven at 95.0% confidence

Large virtual page size support.

I have implemented support in the vm for PAGE_SIZE values which are a 
multiple of the hardware page size.  This is primarily useful for two 
things:

1) Shrinking the size of the vm page array so that very large memory x86 
PAE machines may boot.

2) Improving performance of many operations due to decreased page list 
sizes as well as improved efficiency of many vm operations.  In the 
particular application that this was developed for the fs block size, page 
size, and jumbo frame size were all made equal at 8k on a box with 4k 
pages.  This made page flipping etc. very fast.

This has been done with full userland backwards compatibility.  Userland 
still has the ability to map things in native page size chunks.  The 
majority of the system software remains unchanged.  The vm gains some 
complexity and the elf loader gains some complexity since both need to be 
able to deal with native page size and virtual page size.

The real page size is now CPU_PAGE_SIZE while PAGE_SIZE is the virtual 
page size which is the smallest unit of memory handed back by the page 
allocation routines.  KVA is also managed in PAGE_SIZE chunks.  The x86 
pmap code has a small allocator that deals with allocating real pages for 
page table entries.

I wrote this code for a client who would like for it to be in the freebsd 
tree.  However, it does add some complexity and so I doubt freebsd wants 
it unless there is a clear demand for it.  What I'd like to know is, does 
anyone else find this useful?  Do the developers who work on the vm think 
this is just a horrible hack?  Does anyone care about PAE anymore?

Re: Large virtual page size support.

In message <20060117002541.I602 <at> 10.0.0.1>, Jeff Roberson writes:
>I have implemented support in the vm for PAGE_SIZE values which are a 
>multiple of the hardware page size.  This is primarily useful for two 
>things:

Sounds like a good thing to me.

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

RB_GENERATE macro problem

Andrey Chernov pointed out that jemalloc has several public symbols  
that should be static.  Among the offending symbols are those  
generated by the RB_GENERATE macro in sys/tree.h.  RB_GENERATE  
provides no mechanism for making the generated functions static, so  
I'd like to create new interfaces: RB_PROTOTYPE_STATIC and  
RB_GENERATE_STATIC.  This does not introduce any incompatibilities,  
as far as I know.    There is a complete patch at:

http://people.freebsd.org/~jasone/patches/RB_static.diff

In short, this patch does the following:

--------
#define	RB_GENERATE(name, type, field, cmp)			\
	RB_GENERATE_INTERNAL(name, type, field, cmp,)
#define	RB_GENERATE_STATIC(name, type, field, cmp)		\
	RB_GENERATE_INTERNAL(name, type, field, cmp, static)
#define RB_GENERATE_INTERNAL(name, type, field, cmp, attr)	\
attr void							\
name##_RB_INSERT_COLOR(struct name *head, struct type *elm)	\
[...]
--------

Does anyone have any reservations about this change, or suggestions  
for a better method?

Thanks,
Jason

_______________________________________________

Re: Large virtual page size support.

Jeff Roberson wrote:

> I have implemented support in the vm for PAGE_SIZE values which are a 
> multiple of the hardware page size.  This is primarily useful for two 
> things:

Mach (and the VM system we inherrited from it) had this. I beieve it was 
removed with teh comment
"If we need this and someone is willing to support it it can be added 
back" .

It always seemed like in interesting idea and I'm happy to see that it 
is still being looked at.

>
> 1) Shrinking the size of the vm page array so that very large memory 
> x86 PAE machines may boot.
>
> 2) Improving performance of many operations due to decreased page list 
> sizes as well as improved efficiency of many vm operations.  In the 
> particular application that this was developed for the fs block size, 
> page size, and jumbo frame size were all made equal at 8k on a box 
> with 4k pages.  This made page flipping etc. very fast.
>
> This has been done with full userland backwards compatibility.  
> Userland still has the ability to map things in native page size 
> chunks.  The majority of the system software remains unchanged.  The 
> vm gains some complexity and the elf loader gains some complexity 
> since both need to be able to deal with native page size and virtual 
> page size.