DragonFly BSD
DragonFly kernel List (threaded) for 2006-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: a take at cache coherency


From: "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>
Date: Tue, 24 Jan 2006 13:43:42 +0100

Csaba Henk wrote:
More concretely, cache_unlink_parent should iterate
cache_shadow_detach() over the list of shadowing entries (as a tweak,
there might be a flag which asks for not doing so).

I think this would settle renaming issues.

Similar mechanisms could be used to maintain groupwise namecache
attibutes in each member of the shadow group, not just at the head. This
way your greatest annoyances (including the API muck-up) could be
solved.

We could keep the locking mechanism as it is in my patch. That's
transparent to the users anyway.

What do you think?

How about this:


We need to linearize the cache entries anyways now, as we can't maintain a tree structure with doubly linked lists.

- have a ncp_shadowroot
- have a ncp_shadowlink which maintains a single linked list to all other entries in the group
- this way we don't have to run through all entries every time when doing locking. we just lock ncp->ncp_shadowroot->ncp_exlocks++.


both entries would be set to NULL in a normal (non-shadowed) ncp.

now, if we want to e.g. rename the whole group, we just start at ncp_shadowroot and cycle through ncp_shadowlinks.

I don't know what matt thought of cache coherency because I don't know the usage model, but what we are doing now at least does its job for nullfs et al.

how do you like this?

the only thing that (still) bothers me is: what happens if somebody locks (cache_lookup) an unresolved (and thus unconnected) nullncp and locks the shadowed ncp (where the system doesn't know about yet about this connection). imagine two processes doing this, each in different order:

time	thread1			thread2
1	lock null		lock lower
2	resolve null (blocks)	lock null (blocks)

we have a deadlock. resolving null means having to lock lower, but this fails as another thread already obtained the lock.

hm. thinking about that we just have to give up the lock while resolving null... i hope that's enough

cheers
  simon

--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]