From: Andrew Morton <akpm@linux-foundation.org>
To: Philipp Reisner <philipp.reisner@linbit.com>
Cc: linux-kernel@vger.kernel.org, Jens Axboe <jens.axboe@oracle.com>,
Greg KH <gregkh@suse.de>, Neil Brown <neilb@suse.de>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Sam Ravnborg <sam@ravnborg.org>, Dave Jones <davej@redhat.com>,
Nikanth Karthikesan <knikanth@suse.de>,
"Lars Marowsky-Bree" <lmb@suse.de>,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
Kyle Moffett <kyle@moffetthome.net>,
Bart Van Assche <bart.vanassche@gmail.com>,
Lars Ellenberg <lars.ellenberg@linbit.com>
Subject: Re: [PATCH 02/16] DRBD: lru_cache
Date: Fri, 1 May 2009 01:59:56 -0700 [thread overview]
Message-ID: <20090501015956.ef663e9b.akpm@linux-foundation.org> (raw)
In-Reply-To: <1241090812-13516-3-git-send-email-philipp.reisner@linbit.com>
On Thu, 30 Apr 2009 13:26:38 +0200 Philipp Reisner <philipp.reisner@linbit.com> wrote:
> The lru_cache is a fixed size cache of equal sized objects. It allows its
> users to do arbitrary transactions in case an element in the cache needs to
> be replaced. Its replacement policy is LRU.
>
None of this really looks drbd-specific.
Would it not be better to present this as a general library function?
lib/lru_cache.c?
I think I might have asked this before. If I did, then thwap-to-you
for not permanently answering it in the changelog ;)
>
> ...
>
> +#define lc_e_base(lc) ((char *)((lc)->slot + (lc)->nr_elements))
> +#define lc_entry(lc, i) ((struct lc_element *) \
> + (lc_e_base(lc) + (i)*(lc)->element_size))
> +#define lc_index_of(lc, e) (((char *)(e) - lc_e_base(lc))/(lc)->element_size)
The macros reference their arguments multiple times and hence are
inefficient and/or buggy and/or unpredictable when passed an expression
with side-effects.
If possible this should be fixed by turning them into regular C
functions. Inlined C functions if that makes sense (it frequently
doesn't).
A pleasing side-effect of this conversion is that for some reason
developers are more likely to document C functions than they are macros
(hint).
I don't understand what these macros are doing and can't be bothered
reverse-engineering the code to work that out. But all the typecasting
looks fishy.
>
> ...
>
> +static inline void lc_init(struct lru_cache *lc,
> + const size_t bytes, const char *name,
> + const unsigned int e_count, const size_t e_size,
> + void *private_p)
> +{
> + struct lc_element *e;
> + unsigned int i;
> +
> + BUG_ON(!e_count);
> +
> + memset(lc, 0, bytes);
> + INIT_LIST_HEAD(&lc->in_use);
> + INIT_LIST_HEAD(&lc->lru);
> + INIT_LIST_HEAD(&lc->free);
> + lc->element_size = e_size;
> + lc->nr_elements = e_count;
> + lc->new_number = -1;
> + lc->lc_private = private_p;
> + lc->name = name;
> + for (i = 0; i < e_count; i++) {
> + e = lc_entry(lc, i);
> + e->lc_number = LC_FREE;
> + list_add(&e->list, &lc->free);
> + /* memset(,0,) did the rest of init for us */
> + }
> +}
How's about you remove all `inline' keywords from the whole patchset
and then go back and inline the functions where there is a demonstrable
benefit? This function won't be one of them!
>
> ...
>
> +/**
> + * lc_free: Frees memory allocated by lc_alloc.
> + * @lc: The lru_cache object
> + */
> +void lc_free(struct lru_cache *lc)
> +{
> + vfree(lc);
> +}
vmalloc() is a last-resort thing. It generates slower-to-access memory
and can cause internal fragmentation of the vmalloc arena, leading to
total machine failure.
Can it be avoided? Often it _can_ be avoided, and the code falls back
to vmalloc() if the more robust memory allocation schemes failed.
> +/**
> + * lc_reset: does a full reset for @lc and the hash table slots.
> + * It is roughly the equivalent of re-allocating a fresh lru_cache object,
> + * basically a short cut to lc_free(lc); lc = lc_alloc(...);
> + */
Comment purports to be kerneldoc but doesn't document the formal argument.
> +void lc_reset(struct lru_cache *lc)
> +{
> + lc_init(lc, size_of_lc(lc->nr_elements, lc->element_size), lc->name,
> + lc->nr_elements, lc->element_size, lc->lc_private);
> +}
> +
> +size_t lc_printf_stats(struct seq_file *seq, struct lru_cache *lc)
> +{
> + /* NOTE:
> + * total calls to lc_get are
> + * (starving + hits + misses)
> + * misses include "dirty" count (update from an other thread in
> + * progress) and "changed", when this in fact lead to an successful
> + * update of the cache.
> + */
> + return seq_printf(seq, "\t%s: used:%u/%u "
> + "hits:%lu misses:%lu starving:%lu dirty:%lu changed:%lu\n",
> + lc->name, lc->used, lc->nr_elements,
> + lc->hits, lc->misses, lc->starving, lc->dirty, lc->changed);
> +}
> +
> +static unsigned int lc_hash_fn(struct lru_cache *lc, unsigned int enr)
> +{
> + return enr % lc->nr_elements;
> +}
> +
> +
> +/**
> + * lc_find: Returns the pointer to an element, if the element is present
> + * in the hash table. In case it is not this function returns NULL.
Unfortunately the above must be done in a single 140 column line -
kerneldoc doesn't understand leading lines which have a newline in the
middle.
Please review all kerneldoc comments in the patchset - I won't commeent
on them further.
> + * @lc: The lru_cache object
> + * @enr: element number
> + */
> +struct lc_element *lc_find(struct lru_cache *lc, unsigned int enr)
> +{
> + struct hlist_node *n;
> + struct lc_element *e;
> +
> + BUG_ON(!lc);
> + hlist_for_each_entry(e, n, lc->slot + lc_hash_fn(lc, enr), colision) {
> + if (e->lc_number == enr)
> + return e;
> + }
> + return NULL;
> +}
> +
>
> ...
>
So I assume that the caller of this facility must provide the locking
for its internals. Is that documented somewhere?
next prev parent reply other threads:[~2009-05-01 9:08 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 11:26 [PATCH 00/16] DRBD: a block device for HA clusters Philipp Reisner
2009-04-30 11:26 ` [PATCH 01/16] DRBD: major.h Philipp Reisner
2009-04-30 11:26 ` [PATCH 02/16] DRBD: lru_cache Philipp Reisner
2009-04-30 11:26 ` [PATCH 03/16] DRBD: activity_log Philipp Reisner
2009-04-30 11:26 ` [PATCH 04/16] DRBD: bitmap Philipp Reisner
2009-04-30 11:26 ` [PATCH 05/16] DRBD: request Philipp Reisner
2009-04-30 11:26 ` [PATCH 06/16] DRBD: userspace_interface Philipp Reisner
2009-04-30 11:26 ` [PATCH 07/16] DRBD: internal_data_structures Philipp Reisner
2009-04-30 11:26 ` [PATCH 08/16] DRBD: main Philipp Reisner
2009-04-30 11:26 ` [PATCH 09/16] DRBD: receiver Philipp Reisner
2009-04-30 11:26 ` [PATCH 10/16] DRBD: proc Philipp Reisner
2009-04-30 11:26 ` [PATCH 11/16] DRBD: worker Philipp Reisner
2009-04-30 11:26 ` [PATCH 12/16] DRBD: variable_length_integer_encoding Philipp Reisner
2009-04-30 11:26 ` [PATCH 13/16] DRBD: misc Philipp Reisner
2009-04-30 11:26 ` [PATCH 14/16] DRBD: tracepoint_probes Philipp Reisner
2009-04-30 11:26 ` [PATCH 15/16] DRBD: documentation Philipp Reisner
2009-04-30 11:26 ` [PATCH 16/16] DRBD: final Philipp Reisner
2009-05-02 15:45 ` [PATCH 12/16] DRBD: variable_length_integer_encoding James Bottomley
2009-05-02 17:29 ` Lars Ellenberg
2009-05-02 15:44 ` [PATCH 10/16] DRBD: proc James Bottomley
2009-05-02 20:23 ` Lars Ellenberg
2009-05-02 15:41 ` [PATCH 04/16] DRBD: bitmap James Bottomley
2009-05-02 17:28 ` Lars Ellenberg
2009-05-03 5:21 ` Neil Brown
2009-05-03 7:38 ` Lars Ellenberg
2009-05-05 17:48 ` Lars Marowsky-Bree
2009-05-05 17:51 ` James Bottomley
2009-05-05 22:26 ` Neil Brown
2009-05-01 9:01 ` [PATCH 03/16] DRBD: activity_log Andrew Morton
2009-05-02 17:00 ` Lars Ellenberg
2009-05-01 8:59 ` Andrew Morton [this message]
2009-05-02 15:26 ` [PATCH 02/16] DRBD: lru_cache Lars Ellenberg
2009-05-02 17:58 ` Andrew Morton
2009-05-02 18:13 ` Lars Ellenberg
2009-05-02 18:26 ` Andrew Morton
2009-05-02 19:39 ` Lars Ellenberg
2009-05-02 23:51 ` Kyle Moffett
2009-05-03 6:27 ` Lars Ellenberg
2009-05-03 14:06 ` Kyle Moffett
2009-05-03 22:48 ` Lars Ellenberg
2009-05-04 0:48 ` Kyle Moffett
2009-05-04 1:01 ` Kyle Moffett
2009-05-04 16:12 ` Rik van Riel
2009-05-04 16:15 ` Lars Ellenberg
2009-05-01 8:59 ` [PATCH 01/16] DRBD: major.h Andrew Morton
2009-05-01 8:59 ` [PATCH 00/16] DRBD: a block device for HA clusters Andrew Morton
2009-05-01 11:15 ` Lars Marowsky-Bree
2009-05-01 13:14 ` Dave Jones
2009-05-01 19:14 ` Andrew Morton
2009-05-05 4:05 ` Christian Kujau
2009-05-02 7:33 ` Bart Van Assche
2009-05-03 5:36 ` Willy Tarreau
2009-05-03 5:40 ` david
2009-05-03 14:21 ` James Bottomley
2009-05-03 14:36 ` david
2009-05-03 14:45 ` James Bottomley
2009-05-03 14:56 ` david
2009-05-03 15:09 ` James Bottomley
2009-05-03 15:22 ` david
2009-05-03 15:38 ` James Bottomley
2009-05-03 15:48 ` david
2009-05-03 16:02 ` James Bottomley
2009-05-03 16:13 ` david
2009-05-04 8:28 ` Philipp Reisner
2009-05-04 17:24 ` James Bottomley
2009-05-05 8:21 ` Philipp Reisner
2009-05-05 14:09 ` James Bottomley
2009-05-05 15:56 ` Philipp Reisner
2009-05-05 17:05 ` James Bottomley
2009-05-05 21:45 ` Philipp Reisner
2009-05-05 21:53 ` James Bottomley
2009-05-06 8:17 ` Philipp Reisner
2009-05-05 15:03 ` Bart Van Assche
2009-05-05 15:57 ` Philipp Reisner
2009-05-05 17:38 ` Lars Marowsky-Bree
2009-05-03 10:06 ` Philipp Reisner
2009-05-03 10:15 ` Thomas Backlund
2009-05-03 5:53 ` Neil Brown
2009-05-03 6:24 ` david
2009-05-03 8:29 ` Lars Ellenberg
2009-05-03 11:00 ` Neil Brown
2009-05-03 21:32 ` Lars Ellenberg
2009-05-04 16:12 ` Lars Marowsky-Bree
2009-05-05 22:08 ` Lars Ellenberg
-- strict thread matches above, loose matches on Subject: below --
2009-05-15 12:10 Philipp Reisner
2009-05-15 12:10 ` [PATCH 01/16] DRBD: major.h Philipp Reisner
2009-05-15 12:10 ` [PATCH 02/16] DRBD: lru_cache Philipp Reisner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090501015956.ef663e9b.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bart.vanassche@gmail.com \
--cc=davej@redhat.com \
--cc=gregkh@suse.de \
--cc=jens.axboe@oracle.com \
--cc=knikanth@suse.de \
--cc=kyle@moffetthome.net \
--cc=lars.ellenberg@linbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@suse.de \
--cc=nab@linux-iscsi.org \
--cc=neilb@suse.de \
--cc=philipp.reisner@linbit.com \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox