From: David Woodhouse <dwmw2@infradead.org>
To: Jasmine Strong <jasmine@hex.linuxgrrls.org>
Cc: John Hall <John.Hall@optionexist.co.uk>,
"Linux MTD list (E-mail)" <linux-mtd@lists.infradead.org>
Subject: Re: Stable cvs version for 2.4
Date: Wed, 04 Sep 2002 15:37:00 +0100 [thread overview]
Message-ID: <547.1031150220@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0209041519170.22265-100000@hex.linuxgrrls.org>
jasmine@hex.linuxgrrls.org said:
> Yes. uCLinux, anyway. Pointers should always be treated as opaque
> unless you have a *really* good reason not to.
I have 8000 reasons not to:
# grep node_frag /proc/slabinfo
jffs2_node_frag 8028 8064 28 64 64 1
At a gratuitous extra 4 bytes per object, that's... ok, well it's only
wasting 32KiB which is less than I expected, but it still annoys me.
> (Architectures that don't always use word-aligned pointers include
> m68k and ARM Thumb.)
Even when we're allocating from the slab and the object in question is a
structure of size which is an even number?
Even so, I'd assume that we care even _more_ about that 32KiB on uCLinux, so
maybe it's worth adding 1 byte of padding to the structure there and
manually aligning the pointer after allocating, or something. We only need
1 bit, after all. Or we could use the _top_ bit on uCLinux, perhaps?
--
dwmw2
next prev parent reply other threads:[~2002-09-04 14:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-03 10:09 Stable cvs version for 2.4 John Hall
2002-09-03 12:29 ` David Woodhouse
2002-09-04 0:18 ` David Woodhouse
2002-09-04 1:14 ` Jasmine Strong
2002-09-04 8:51 ` David Woodhouse
2002-09-04 14:21 ` Jasmine Strong
2002-09-04 14:37 ` David Woodhouse [this message]
2002-09-04 14:46 ` Allen Curtis
2002-09-04 14:54 ` Jasmine Strong
2002-09-04 15:17 ` Steve Wahl
2002-09-04 15:26 ` David Woodhouse
2002-09-04 15:20 ` David Woodhouse
2002-09-04 15:33 ` Jasmine Strong
2002-09-04 15:44 ` David Woodhouse
2002-09-04 15:50 ` Allen Curtis
2002-09-04 15:54 ` David Woodhouse
2002-09-04 14:49 ` Jasmine Strong
2002-09-04 15:06 ` David Woodhouse
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=547.1031150220@redhat.com \
--to=dwmw2@infradead.org \
--cc=John.Hall@optionexist.co.uk \
--cc=jasmine@hex.linuxgrrls.org \
--cc=linux-mtd@lists.infradead.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