From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Shrink thread_info a bit
Date: Wed, 26 Oct 2011 08:11:59 +0100 [thread overview]
Message-ID: <20111026071159.GA9165@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20111025144110.GA2043@localhost.localdomain>
Hi Dave,
On Tue, Oct 25, 2011 at 03:41:11PM +0100, Dave Martin wrote:
> On Mon, Oct 24, 2011 at 02:18:53PM +0100, Will Deacon wrote:
> >
> > Can we also shrink the contents of fp_state when AEABI && !OABI_COMPAT?
>
> Is this the right config combination to indicate that the FPA ABI will
> not be supported? I'm assuming so, since that's the condition which
> currently disallows CONFIG_NWFPE.
>
> I'm not saying it's not ... I'm just unsure.
Well, we basically just want to check whether or not we might have OABI
executables in userspace so I think this is the right way of doing that.
I toyed with doing something like !CONFIG_VFP but that doesn't help with the
compat stuff.
> Note that the FPA state (35 words) is not that much smaller than the
> iwmmxt state (38 words), so not much space would be saved by shrinking
> that union.
Right, but the IWMMXT part of the union is already predicated on
CONFIG_IWMMXT so the goal is to have an empty union for the common case
(EABI and no IWMMXT).
> I wonder whether fpstate can go away completely on platforms which have
> neither fpa nor iwmmxt however. That would be a more significant saving.
> Is it used for anything else?
That's kind of the idea, but I was just going to leave it empty.
> > It's slightly more involved as ptrace and core-dumping would need some
> > similar treatment. We probably need to keep the union kicking around
> > though, since the iwmmxt state is held in there.
>
> We would need some sensible error return from the ptrace calls to access
> the FPA registers. PTRACE_GETREGSET (not currently working on ARM since
> the relevant generic code is #ifdef'd on CONFIG_HAVE_ARCH_TRACEHOOK for
> some reason) returns -EINVAL when requesting a regset that isn't there.
>
> Fixing coredumps should be relatively easy -- I think we just need to
> change arm_regsets[] in arch/arm/kernel/ptrace.c appropriately.
Russell also pointed out that we need to hack some assembly code for this to
work, but I can't say I've looked into it yet.
Will
next prev parent reply other threads:[~2011-10-26 7:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-24 12:48 [PATCH] Shrink thread_info a bit Russell King - ARM Linux
2011-10-24 13:06 ` Baruch Siach
2011-10-24 13:08 ` Russell King - ARM Linux
2011-10-24 13:18 ` Will Deacon
2011-10-24 13:20 ` Russell King - ARM Linux
2011-10-25 14:41 ` Dave Martin
2011-10-26 7:11 ` Will Deacon [this message]
2011-10-24 14:33 ` Tim Bird
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=20111026071159.GA9165@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@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;
as well as URLs for NNTP newsgroup(s).