[OpenAFS-devel] 2.6.16 linux and d_cache

[William John Murray]

  Hello all,
         I am still trying to get AFS on 2.6.16 linux.
The latest snapshots, and 1.5.0 have a new routine in afs_callback.c
which does not compile:
'struct dentry=E2=80=99 has no member named =E2=80=98d_child'

This seems to be due to the patch at the bottom.

So now we have:
	/*
	 * d_child and d_rcu can share memory
	 */
	union {
		struct list_head d_child;	/* child of parent list */
	 	struct rcu_head d_rcu;
	} d_u;

Does anyone know how should this be d_child be referenced?
d_u.d_cache is wrong...
   Thank you,
           Bill

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
commit 5160ee6fc891a9ca114be0e90fa6655647bb64b2
Author: Eric Dumazet <dada1@cosmosbay.com>
Date:   Sun Jan 8 01:03:32 2006 -0800

[PATCH] shrink dentry struct
Some long time ago, dentry struct was carefully tuned so that on 32 bits
UP, sizeof(struct dentry) was exactly 128, ie a power of 2, and a
multiple
of memory cache lines.
   =20
Then RCU was added and dentry struct enlarged by two pointers, with nice
results for SMP, but not so good on UP, because breaking the above
tuning
(128 + 8 =3D 136 bytes)
   =20
This patch reverts this unwanted side effect, by using an union (d_u),
where d_rcu and d_child are placed so that these two fields can share
their memory needs.
   =20
At the time d_free() is called (and d_rcu is really used), d_child is
known to be empty and not touched by the dentry freeing.
   =20
Lockless lookups only access d_name, d_parent, d_lock, d_op, d_flags (so
the previous content of d_child is not needed if said dentry was
unhashed
but still accessed by a CPU because of RCU constraints)
   =20
As dentry cache easily contains millions of entries, a size reduction is
worth the extra complexity of the ugly C union.