public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pan Xinhui <xinhuix.pan@intel.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"x86@kernel.org" <x86@kernel.org>, "bp@suse.de" <bp@suse.de>,
	"Kani, Toshimitsu" <toshi.kani@hp.com>,
	"jgross@suse.com" <jgross@suse.com>,
	"mcgrof@suse.com" <mcgrof@suse.com>,
	"mnipxh@163.com" <mnipxh@163.com>,
	"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>,
	"Elliott, Robert (Server Storage)" <Elliott@hp.com>
Subject: [PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list
Date: Fri, 24 Jul 2015 11:11:57 +0800	[thread overview]
Message-ID: <55B1ACFD.9020200@intel.com> (raw)

From: Pan Xinhui <xinhuix.pan@intel.com>

There are many nodes in the PAT memtype rb-tree. When we dump this tree
we call kzalloc every time to copy nodes. Actually these kzalloc are not
necessary. Lets do a optimization now.

Let seq_file core create an *entry* when open and free it when release.
*entry* is stored as seq->private, so we can use it in seq_operations
callback who traverse/output the PAT memtype rb-tree only. Lots of
unnecessary kzalloc could be avoided now.

Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
---
v1 -> v2:
	Use seq_open/release_private. let seq_file core handle memory alloc/free.
	seq_operations callbacks now only traverse/output the PAT rb-tree.
---
 arch/x86/mm/pat.c | 28 ++++++++++------------------
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 268b2c8..53920be 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -1001,41 +1001,33 @@ EXPORT_SYMBOL_GPL(pgprot_writethrough);
 
 #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
 
-static struct memtype *memtype_get_idx(loff_t pos)
+static struct memtype *memtype_get_idx(struct memtype *entry, loff_t pos)
 {
-	struct memtype *print_entry;
 	int ret;
 
-	print_entry  = kzalloc(sizeof(struct memtype), GFP_KERNEL);
-	if (!print_entry)
-		return NULL;
-
 	spin_lock(&memtype_lock);
-	ret = rbt_memtype_copy_nth_element(print_entry, pos);
+	ret = rbt_memtype_copy_nth_element(entry, pos);
 	spin_unlock(&memtype_lock);
 
-	if (!ret) {
-		return print_entry;
-	} else {
-		kfree(print_entry);
-		return NULL;
-	}
+	return ret ? NULL : entry;
 }
 
 static void *memtype_seq_start(struct seq_file *seq, loff_t *pos)
 {
+	struct memtype *entry = seq->private;
+
 	if (*pos == 0) {
 		++*pos;
 		seq_puts(seq, "PAT memtype list:\n");
 	}
 
-	return memtype_get_idx(*pos);
+	return memtype_get_idx(entry, *pos);
 }
 
 static void *memtype_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 {
 	++*pos;
-	return memtype_get_idx(*pos);
+	return memtype_get_idx((struct memtype *)v, *pos);
 }
 
 static void memtype_seq_stop(struct seq_file *seq, void *v)
@@ -1048,7 +1040,6 @@ static int memtype_seq_show(struct seq_file *seq, void *v)
 
 	seq_printf(seq, "%s @ 0x%Lx-0x%Lx\n", cattr_name(print_entry->type),
 			print_entry->start, print_entry->end);
-	kfree(print_entry);
 
 	return 0;
 }
@@ -1062,14 +1053,15 @@ static const struct seq_operations memtype_seq_ops = {
 
 static int memtype_seq_open(struct inode *inode, struct file *file)
 {
-	return seq_open(file, &memtype_seq_ops);
+	return seq_open_private(file, &memtype_seq_ops,
+							sizeof(struct memtype));
 }
 
 static const struct file_operations memtype_fops = {
 	.open    = memtype_seq_open,
 	.read    = seq_read,
 	.llseek  = seq_lseek,
-	.release = seq_release,
+	.release = seq_release_private,
 };
 
 static int __init pat_memtype_list_init(void)
-- 
1.9.1

             reply	other threads:[~2015-07-24  3:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24  3:11 Pan Xinhui [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-07-23  9:54 [PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list Pan Xinhui
2015-07-23 14:53 ` Elliott, Robert (Server Storage)
2015-07-24  2:40   ` Pan Xinhui

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=55B1ACFD.9020200@intel.com \
    --to=xinhuix.pan@intel.com \
    --cc=Elliott@hp.com \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@suse.com \
    --cc=mingo@redhat.com \
    --cc=mnipxh@163.com \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hp.com \
    --cc=x86@kernel.org \
    --cc=yanmin_zhang@linux.intel.com \
    /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