From: Andrew Morton <akpm@linux-foundation.org>
To: Artem Bityutskiy <dedekind@infradead.org>
Cc: linux-kernel@vger.kernel.org, haver@vnet.ibm.com,
hch@infradead.org, dwmw2@infradead.org,
jwboyer@linux.vnet.ibm.com, dedekind@infradead.org
Subject: Re: [PATCH 10/22 take 3] UBI: EBA unit
Date: Thu, 15 Mar 2007 11:07:03 -0800 [thread overview]
Message-ID: <20070315110703.1c2dcce4.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070314152024.1112.15655.sendpatchset@localhost.localdomain>
There's way too much code here to expect it to get decently reviewed, alas.
> On Wed, 14 Mar 2007 17:20:24 +0200 Artem Bityutskiy <dedekind@infradead.org> wrote:
>
> ...
>
> +/**
> + * leb_get_ver - get logical eraseblock version.
> + *
> + * @ubi: the UBI device description object
> + * @vol_id: the volume ID
> + * @lnum: the logical eraseblock number
> + *
> + * The logical eraseblock has to be locked. Note, all this leb_ver stuff is
> + * obsolete and will be removed eventually. FIXME: to be removed together with
> + * leb_ver support.
> + */
> +static inline int leb_get_ver(struct ubi_info *ubi, int vol_id, int lnum)
> +{
> + int idx, leb_ver;
> +
> + idx = vol_id2idx(ubi, vol_id);
> +
> + spin_lock(&ubi->eba.eba_tbl_lock);
> + ubi_assert(ubi->eba.eba_tbl[idx].recs);
> + leb_ver = ubi->eba.eba_tbl[idx].recs[lnum].leb_ver;
> + spin_unlock(&ubi->eba.eba_tbl_lock);
> +
> + return leb_ver;
> +}
I very much doubt that the locking in this function (and in the similar
ones here) does anything useful.
> +static unsigned long long next_sqnum(struct ubi_info *ubi)
> +{
> + unsigned long long sqnum;
> +
> + spin_lock(&ubi->eba.eba_tbl_lock);
> + sqnum = ubi->eba.global_sq_cnt++;
> + spin_unlock(&ubi->eba.eba_tbl_lock);
> +
> + return sqnum;
> +}
That one makes sense,
> +static inline void leb_map(struct ubi_info *ubi, int vol_id, int lnum, int pnum)
> +{
> + int idx;
> +
> + idx = vol_id2idx(ubi, vol_id);
> + spin_lock(&ubi->eba.eba_tbl_lock);
> + ubi_assert(ubi->eba.eba_tbl[idx].recs);
> + ubi_assert(ubi->eba.eba_tbl[idx].recs[lnum].pnum < 0);
> + ubi->eba.eba_tbl[idx].recs[lnum].pnum = pnum;
> + spin_unlock(&ubi->eba.eba_tbl_lock);
> +}
I doubt if that one does.
> +/**
> + * leb_unmap - un-map a logical eraseblock.
> + *
> + * @ubi: the UBI device description object
> + * @vol_id: the volume ID
> + * @lnum: the logical eraseblock number to unmap
> + *
> + * This function un-maps a logical eraseblock and increases its version. The
> + * logical eraseblock has to be locked.
> + */
> +static inline void leb_unmap(struct ubi_info *ubi, int vol_id, int lnum)
The patch is full of nutty inlining.
Suggestion: just remove all of it. Then reintroduce inlining in only
those places where a benefit is demonstrable. Reduced code size according to
/bin/size would be a suitable metric.
> +static inline int leb2peb(struct ubi_info *ubi, int vol_id, int lnum)
> +{
> + int idx, pnum;
> +
> + idx = vol_id2idx(ubi, vol_id);
> +
> + spin_lock(&ubi->eba.eba_tbl_lock);
> + ubi_assert(ubi->eba.eba_tbl[idx].recs);
> + pnum = ubi->eba.eba_tbl[idx].recs[lnum].pnum;
> + spin_unlock(&ubi->eba.eba_tbl_lock);
> +
> + return pnum;
> +}
Again, the locking seems pointless.
next prev parent reply other threads:[~2007-03-15 19:09 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-14 15:19 [PATCH 00/22 take 3] UBI: Unsorted Block Images Artem Bityutskiy
2007-03-14 15:19 ` [PATCH 01/22 take 3] UBI: on-flash data structures header Artem Bityutskiy
2007-03-14 15:19 ` [PATCH 02/22 take 3] UBI: user-space API header Artem Bityutskiy
2007-03-14 15:19 ` [PATCH 03/22 take 3] UBI: kernel-space " Artem Bityutskiy
2007-03-14 15:19 ` [PATCH 04/22 take 3] UBI: internal header Artem Bityutskiy
2007-03-14 15:19 ` [PATCH 05/22 take 3] UBI: startup code Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 06/22 take 3] UBI: scanning unit Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 07/22 take 3] UBI: I/O unit Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 08/22 take 3] UBI: volume table unit Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 09/22 take 3] UBI: wear-leveling unit Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 10/22 take 3] UBI: EBA unit Artem Bityutskiy
2007-03-15 19:07 ` Andrew Morton [this message]
2007-03-15 21:24 ` Randy Dunlap
2007-03-15 23:29 ` Josh Boyer
2007-03-16 1:49 ` Randy Dunlap
2007-03-16 10:23 ` Artem Bityutskiy
2007-03-16 10:21 ` Artem Bityutskiy
2007-03-16 14:55 ` Randy Dunlap
2007-03-16 10:14 ` Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 11/22 take 3] UBI: user-interfaces unit Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 12/22 take 3] UBI: update functionality Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 13/22 take 3] UBI: accounting unit Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 14/22 take 3] UBI: volume management functionality Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 15/22 take 3] UBI: sysfs functionality Artem Bityutskiy
2007-03-14 15:20 ` [PATCH 16/22 take 3] UBI: character devices functionality Artem Bityutskiy
2007-03-14 15:21 ` [PATCH 17/22 take 3] UBI: gluebi functionality Artem Bityutskiy
2007-03-14 15:21 ` [PATCH 18/22 take 3] UBI: misc stuff Artem Bityutskiy
2007-03-14 15:21 ` [PATCH 19/22 take 3] UBI: debugging stuff Artem Bityutskiy
2007-03-14 15:21 ` [PATCH 20/22 take 3] UBI: JFFS2 UBI support Artem Bityutskiy
2007-03-14 15:21 ` [PATCH 21/22 take 3] UBI: update MAINTAINERS Artem Bityutskiy
2007-03-14 15:21 ` [PATCH 22/22 take 3] UBI: Linux build integration Artem Bityutskiy
2007-03-18 16:27 ` [PATCH 00/22 take 3] UBI: Unsorted Block Images Matt Mackall
2007-03-18 16:49 ` Artem Bityutskiy
2007-03-18 19:18 ` Matt Mackall
2007-03-18 20:31 ` Josh Boyer
2007-03-19 17:08 ` Matt Mackall
2007-03-19 18:16 ` Josh Boyer
2007-03-19 19:54 ` Matt Mackall
2007-03-19 20:18 ` Artem Bityutskiy
2007-03-19 21:05 ` Thomas Gleixner
2007-03-19 22:32 ` Matt Mackall
2007-03-20 0:42 ` Thomas Gleixner
2007-03-20 1:05 ` Matt Mackall
2007-03-20 6:28 ` Thomas Gleixner
2007-03-21 11:05 ` Jörn Engel
2007-03-21 11:25 ` Thomas Gleixner
2007-03-21 11:35 ` Jörn Engel
2007-03-21 11:57 ` Thomas Gleixner
2007-03-21 12:31 ` Jörn Engel
2007-03-21 12:39 ` Artem Bityutskiy
2007-03-21 11:36 ` Artem Bityutskiy
2007-03-25 20:08 ` Jörn Engel
2007-03-25 21:49 ` David Lang
2007-03-25 22:55 ` Jörn Engel
2007-03-25 23:46 ` David Woodhouse
2007-03-26 0:01 ` Jörn Engel
2007-03-26 0:21 ` David Woodhouse
2007-03-26 1:04 ` Jörn Engel
2007-03-26 9:45 ` David Woodhouse
2007-03-26 9:51 ` Jörn Engel
2007-03-26 10:07 ` David Woodhouse
2007-03-26 10:02 ` Thomas Gleixner
2007-03-26 10:49 ` Artem Bityutskiy
2007-03-26 11:30 ` Jörn Engel
2007-03-19 21:06 ` Artem Bityutskiy
2007-03-19 21:36 ` Matt Mackall
2007-03-20 0:43 ` Thomas Gleixner
2007-03-20 12:25 ` Artem Bityutskiy
2007-03-20 13:52 ` Theodore Tso
2007-03-20 15:14 ` Artem Bityutskiy
2007-03-20 15:59 ` Josh Boyer
2007-03-20 18:58 ` David Lang
2007-03-20 20:05 ` Artem Bityutskiy
2007-03-20 21:36 ` David Woodhouse
2007-03-21 8:54 ` Artem Bityutskiy
2007-03-20 21:32 ` David Woodhouse
2007-03-21 13:03 ` Jörn Engel
2007-03-20 22:03 ` Theodore Tso
2007-03-21 8:44 ` Artem Bityutskiy
2007-03-21 13:50 ` Theodore Tso
2007-03-21 13:59 ` Josh Boyer
2007-03-21 14:02 ` Artem Bityutskiy
2007-03-21 15:38 ` Frank Haverkamp
2007-03-21 20:26 ` David Lang
2007-03-20 12:13 ` Josh Boyer
2007-03-19 19:03 ` Thomas Gleixner
2007-03-19 20:12 ` Matt Mackall
2007-03-19 21:04 ` Thomas Gleixner
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=20070315110703.1c2dcce4.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dedekind@infradead.org \
--cc=dwmw2@infradead.org \
--cc=haver@vnet.ibm.com \
--cc=hch@infradead.org \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.