Message-ID: <20151215110809.GA1899@quack.suse.cz>
Date:	Tue, 15 Dec 2015 12:08:09 +0100
From:	Jan Kara <jack@...e.cz>
To:	Andreas Grünbacher 
	<andreas.gruenbacher@...il.com>
Cc:	Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>,
	linux-ext4@...r.kernel.org, Laurent GUERBY <laurent@...rby.net>,
	Andreas Dilger <adilger@...ger.ca>
Subject: Re: [PATCH 1/6] mbcache2: Reimplement mbcache

  Hello,

On Sat 12-12-15 00:58:30, Andreas Grünbacher wrote:
> > +/*
> > + * Mbcache is a simple key-value store.
> > + Keys need not be unique, however
> > + * key-value pairs are expected to be unique (we use this in
> > + * mb2_cache_entry_delete_block()).
> 
> This comment is very confusing. Could you say what the keys and values
> are and what that kind of cache is used for so that people will have a
> chance of understanding what's going on?

I've added some more explanations to the comment.

> > + * We provide functions for creation and removal of entries, search by key,
> > + * and a special "delete entry with given key-value pair" operation. Fixed
> > + * size hash table is used for fast key lookups.
> > + */
> 
> Have you had a look at rhashtables? They would give us lockless
> lookups and they would automatically grow, at somewhat more
> complexity.

No, I didn't have a look at them. As I said I'm not sure the complexity is
worth it. We can have a look into it in future. Lockless lookups could
provide interesting speedups for the case with limited number of unique
xattr blocks. Case with lots of unique xattr blocks will not benefit at
all since that is write-mostly workload...

> > +/*
> > + * mb2_cache_entry_delete - delete entry from cache
> > + * @cache - cache where the entry is
> > + * @entry - entry to delete
> > + *
> > + * Delete entry from cache. The entry is unhashed and deleted from the lru list
> > + * so it cannot be found. We also drop the reference to @entry caller gave us.
> > + * However entry need not be freed if there's someone else still holding a
> > + * reference to it. Freeing happens when the last reference is dropped.
> > + */
> > +void mb2_cache_entry_delete(struct mb2_cache *cache,
> > +                           struct mb2_cache_entry *entry)
> 
> This function should become static; there are no external users.

It's actually completely unused. But if we end up removing entries for
blocks where refcount hit maximum, then it will be used by the fs. Thinking
about removal of entries with max refcount, the slight complication is that
when refcount decreases again, we won't insert the entry in cache unless
someone calls listattr or getattr for inode with that block. So we'll
probably need some more complex logic to avoid this.

I'll first gather some statistics on the lengths of hash chains and hash
chain scanning when there are few unique xattrs to see whether the
complexity is worth it.

> > +/* Shrink number of entries in cache */
> > +static unsigned long mb2_cache_scan(struct shrinker *shrink,
> > +                                   struct shrink_control *sc)
> > +{
> > +       int nr_to_scan = sc->nr_to_scan;
> > +       struct mb2_cache *cache = container_of(shrink, struct mb2_cache,
> > +                                             c_shrink);
> > +       struct mb2_cache_entry *entry;
> > +       struct hlist_bl_head *head;
> > +       unsigned int shrunk = 0;
> > +
> > +       spin_lock(&cache->c_lru_list_lock);
> > +       while (nr_to_scan-- && !list_empty(&cache->c_lru_list)) {
> > +               entry = list_first_entry(&cache->c_lru_list,
> > +                                        struct mb2_cache_entry, e_lru_list);
> > +               list_del_init(&entry->e_lru_list);
> > +               cache->c_entry_count--;
> > +               /*
> > +                * We keep LRU list reference so that entry doesn't go away
> > +                * from under us.
> > +                */
> > +               spin_unlock(&cache->c_lru_list_lock);
> > +               head = entry->e_hash_list_head;
> > +               hlist_bl_lock(head);
> 
> Instead of taking and dropping c_lru_list_lock in the loop, could we
> get away with a simple-to-implement hlist_bl_trylock() and
> cond_resched_lock()?

For now I'd keep things simple. Since we limit number of entries in cache
ourselves, shrinker doesn't get used that often and so the lock traffic on
lru_list_lock from it is minimal...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists