From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932693AbcASJMJ (ORCPT ); Tue, 19 Jan 2016 04:12:09 -0500 Received: from mx2.suse.de ([195.135.220.15]:36148 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932641AbcASJMF (ORCPT ); Tue, 19 Jan 2016 04:12:05 -0500 Date: Tue, 19 Jan 2016 10:12:01 +0100 From: Jean Delvare To: Andy Lutomirski Cc: Pali =?UTF-8?B?Um9ow6Fy?= , platform-driver-x86@vger.kernel.org, linux-kernel Subject: Re: [PATCH] dell-wmi: Stop storing pointers to DMI tables Message-ID: <20160119101201.49c4d4c5@endymion.delvare> In-Reply-To: References: <119170b95d373bc943eb4f16818239bac9fa6c59.1451832667.git.luto@kernel.org> <20160112142538.GB11560@pali> <20160115142719.36eea015@endymion.delvare> <1452880405.4941.0.camel@chaos.site> Organization: SUSE Linux X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andy, On Fri, 15 Jan 2016 12:00:02 -0800, Andy Lutomirski wrote: > UC means uncached. ioremap, on x86, asks for an uncached mapping, so > every memory access (load or store) hits main memory individually. > Assuming that the spec says that whatever physical memory the DMI > tables live in is permitted to be used with cached accesses, asking > for the CPU cache to be permitted on those accesses will make them a > whole lot faster. > > If that isn't safe, you could also just copy each table out of the > ioremap space into normal RAM as needed using MOVNTDQA. I forget what > the helper for that is called, but it basically does a fast streaming > IO read and then writes to normal RAM, memcpy style. Most modern CPUs > support it. I have no idea what is allowed and what isn't, sorry. You would have to check the SMBIOS specification but also the UEFI specification. I have to admit I never understood why dmi_alloc is arch-specific nor why dmi_remap is needed in the first place (and even less why dmi_early_remap is different.) So I'm not going to mess up with that code. I have no idea how costly dmi_remap() is, but certainly it is being called more and more as we can see dmi_walk() gaining in popularity. So if anyone is worried about the performance, I'll be happy to review and test patches. -- Jean Delvare SUSE L3 Support