From: Christoph Hellwig <hch@infradead.org>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: mingo@elte.hu, hpa@zytor.com, tglx@linutronix.de,
andi@firstfloor.org, linux-kernel@vger.kernel.org,
Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [patch 1/2] x86,fpu: split FPU state from task struct
Date: Sat, 23 Feb 2008 22:04:42 -0500 [thread overview]
Message-ID: <20080224030442.GA7282@infradead.org> (raw)
In-Reply-To: <20080224023547.264625000@linux-os.sc.intel.com>
On Sat, Feb 23, 2008 at 06:34:38PM -0800, Suresh Siddha wrote:
> Split the FPU save area from the task struct. This allows easy migration
> of FPU context, and it's generally cleaner. It also allows the following
> two optimizations:
>
> 1) only allocate when the application actually uses FPU, so in the first
> lazy FPU trap. This could save memory for non-fpu using apps. Next patch
> does this lazy allocation.
>
> 2) allocate the right size for the actual cpu rather than 512 bytes always.
> Patches enabling xsave/xrstor support (coming shortly) will take advantage
> of this.
This sounds like a wonderful idea. But I'm a little unhappy with
some of the rather cosmetic things in this patch:
> if (next_p->fpu_counter>5)
> - prefetch(&next->i387.fxsave);
> + prefetch(FXSAVE(next_p));
These macros are rather ugly. If you really want them please
a) make them inlines and lowercase with a descriptive name
b) introduce them in a separate patch before the first real
path in the series.
> +++ linux-2.6-x86/kernel/fork.c 2008-02-23 15:08:53.000000000 -0800
> @@ -87,6 +87,7 @@
> #ifndef __HAVE_ARCH_TASK_STRUCT_ALLOCATOR
> # define alloc_task_struct() kmem_cache_alloc(task_struct_cachep, GFP_KERNEL)
> # define free_task_struct(tsk) kmem_cache_free(task_struct_cachep, (tsk))
> +# define memcpy_task_struct(dst, src) do { *dst = *src; } while (0)
> static struct kmem_cache *task_struct_cachep;
> #endif
>
> @@ -142,6 +143,8 @@
> task_struct_cachep =
> kmem_cache_create("task_struct", sizeof(struct task_struct),
> ARCH_MIN_TASKALIGN, SLAB_PANIC, NULL);
> +#else
> + task_struct_slab_init();
> #endif
>
> /*
> @@ -181,7 +184,8 @@
> return NULL;
> }
>
> - *tsk = *orig;
> + memcpy_task_struct(tsk, orig);
I think this is a bad name for this helper, arch_dup_task_struct
would be more descriptive.
But we actually have an arch hook for this kind of thing called
setup_thread_stack which is used by ia64 and m68k just a few lines
later, so it'd be better to look into having a single hook.
(And possibly rename it to arch_dup_task_struct because the name
is a lot more descriptive)
setup_thread_stack
> + memset(FSAVE(tsk), 0, math_cntxt_size);
> + FSAVE(tsk)->cwd = 0xffff037fu;
> + FSAVE(tsk)->swd = 0xffff0000u;
> + FSAVE(tsk)->twd = 0xffffffffu;
> + FSAVE(tsk)->fos = 0xffff0000u;
Also if you reference the save area so often it'd be better to just
have a local variable for it. Much better readable.
> +struct task_struct * alloc_task_struct(void)
this should be struct task_struct *alloc_task_struct(void)
> +void free_task_struct(struct task_struct *tsk)
> +{
> + kmem_cache_free(task_cntxt_cachep, tsk->thread.cntxt);
> + tsk->thread.cntxt=NULL;
missing spaces around the '='
> -#define I387 (current->thread.i387)
> -#define FPU_info (I387.soft.info)
> +#define I387 (current->thread.cntxt)
> +#define FPU_info (I387->soft.info)
> +#define SOFT(t) (&(t->thread.cntxt->soft))
This is quite butt ugly. But then again it's fpemu, so there's
probably no point touching it until a bored janitor comes around.
next prev parent reply other threads:[~2008-02-24 3:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-24 2:34 [patch 1/2] x86,fpu: split FPU state from task struct Suresh Siddha
2008-02-24 2:34 ` [patch 2/2] x86,fpu: lazy allocation of FPU area Suresh Siddha
2008-02-24 3:08 ` Christoph Hellwig
2008-02-24 12:20 ` Andi Kleen
2008-02-24 16:32 ` Siddha, Suresh B
2008-02-24 3:04 ` Christoph Hellwig [this message]
2008-02-24 7:22 ` [patch 1/2] x86,fpu: split FPU state from task struct Ingo Molnar
2008-02-24 16:30 ` Siddha, Suresh B
-- strict thread matches above, loose matches on Subject: below --
2008-02-24 7:27 Roger While
2008-02-24 16:29 ` Siddha, Suresh B
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=20080224030442.GA7282@infradead.org \
--to=hch@infradead.org \
--cc=andi@firstfloor.org \
--cc=arjan@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
/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.