From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756526AbbGPWnZ (ORCPT ); Thu, 16 Jul 2015 18:43:25 -0400 Received: from terminus.zytor.com ([198.137.202.10]:42642 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755915AbbGPWnY (ORCPT ); Thu, 16 Jul 2015 18:43:24 -0400 Message-ID: <55A83350.1080603@zytor.com> Date: Thu, 16 Jul 2015 15:42:24 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Hansen CC: tglx@linutronix.de, mingo@redhat.com, x86@kernel.org, peterz@infradead.org, bp@alien8.de, luto@amacapital.net, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] x86, fpu: dynamically allocate 'struct fpu' References: <20150716191437.A334FF2E@viggo.jf.intel.com> In-Reply-To: <20150716191437.A334FF2E@viggo.jf.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/16/2015 12:14 PM, Dave Hansen wrote: > The FPU rewrite removed the dynamic allocations of 'struct fpu'. > But, this potentially wastes massive amounts of memory (2k per > task on systems that do not have AVX-512 for instance). > > Instead of having a separate slab, this patch just appends the > space that we need to the 'task_struct' which we dynamically > allocate already. This saves from doing an extra slab allocation > at fork(). The only real downside here is that we have to stick > everything and the end of the task_struct. But, I think the > BUILD_BUG_ON()s I stuck in there should keep that from being too > fragile. > > This survives a quick build and boot in a VM. Does anyone see any > real downsides to this? > No. I have also long advocated for merging task_struct and thread_info into a common structure and get it off the stack; it would improve security and avoid weird corner cases in the irqstack handling. -hpa