All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: torvalds@linux-foundation.org, tj@kernel.org,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, paul.gortmaker@windriver.com,
	davem@davemloft.net, rostedt@goodmis.org, mingo@elte.hu,
	ebiederm@xmission.com, aarcange@redhat.com, ericvh@gmail.com,
	netdev@vger.kernel.org, josh@joshtriplett.org,
	eric.dumazet@gmail.com, mathieu.desnoyers@efficios.com,
	axboe@kernel.dk, agk@redhat.com, dm-devel@redhat.com,
	ccaulfie@redhat.com, teigland@redhat.com,
	Trond.Myklebust@netapp.com, bfields@fieldses.org,
	fweisbec@gmail.com, jesse@nicira.com,
	venkat.x.venkatsubra@oracle.com, ejt@redhat.com,
	snitzer@redhat.com, edumazet@google.com,
	linux-nfs@vger.kernel.org, dev@openvswitch.org,
	rds-devel@oss.oracle.com, lw@cn.fujitsu.com
Subject: Re: [PATCH 01/16] hashtable: introduce a small and naive hashtable
Date: Wed, 15 Aug 2012 09:25:23 +1000	[thread overview]
Message-ID: <20120815092523.00a909ef@notabene.brown> (raw)
In-Reply-To: <1344961490-4068-2-git-send-email-levinsasha928@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

On Tue, 14 Aug 2012 18:24:35 +0200 Sasha Levin <levinsasha928@gmail.com>
wrote:


> +static inline void hash_init_size(struct hlist_head *hashtable, int bits)
> +{
> +	int i;
> +
> +	for (i = 0; i < HASH_SIZE(bits); i++)
> +		INIT_HLIST_HEAD(hashtable + i);
> +}

This seems like an inefficient way to do "memset(hashtable, 0, ...);".
And in many cases it isn't needed as the hash table is static and initialised
to zero.
I note that in the SUNRPC/cache patch you call hash_init(), but in the lockd
patch you don't.  You don't actually need to in either case.

I realise that any optimisation here is for code that is only executed once
per boot, so no big deal, and even the presence of extra code making the
kernel bigger is unlikely to be an issue.  But I'd at least like to see
consistency: Either use hash_init everywhere, even when not needed, or only
use it where absolutely needed which might be no-where because static tables
are already initialised, and dynamic tables can use GFP_ZERO.

And if you keep hash_init_size I would rather see a memset(0)....

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
To: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
	rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org,
	mingo-X9Un+BFzKDI@public.gmane.org,
	ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
	aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	ericvh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org,
	eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org,
	axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org,
	agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	ccaulfie-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	teigland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
	bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
	fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org,
	venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
	ejt-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
	rds-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org,
	lw-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org
Subject: Re: [PATCH 01/16] hashtable: introduce a small and naive hashtable
Date: Wed, 15 Aug 2012 09:25:23 +1000	[thread overview]
Message-ID: <20120815092523.00a909ef@notabene.brown> (raw)
In-Reply-To: <1344961490-4068-2-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

On Tue, 14 Aug 2012 18:24:35 +0200 Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:


> +static inline void hash_init_size(struct hlist_head *hashtable, int bits)
> +{
> +	int i;
> +
> +	for (i = 0; i < HASH_SIZE(bits); i++)
> +		INIT_HLIST_HEAD(hashtable + i);
> +}

This seems like an inefficient way to do "memset(hashtable, 0, ...);".
And in many cases it isn't needed as the hash table is static and initialised
to zero.
I note that in the SUNRPC/cache patch you call hash_init(), but in the lockd
patch you don't.  You don't actually need to in either case.

I realise that any optimisation here is for code that is only executed once
per boot, so no big deal, and even the presence of extra code making the
kernel bigger is unlikely to be an issue.  But I'd at least like to see
consistency: Either use hash_init everywhere, even when not needed, or only
use it where absolutely needed which might be no-where because static tables
are already initialised, and dynamic tables can use GFP_ZERO.

And if you keep hash_init_size I would rather see a memset(0)....

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-08-14 23:26 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-14 16:24 [PATCH 00/16] generic hashtable implementation Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 01/16] hashtable: introduce a small and naive hashtable Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 23:25   ` NeilBrown [this message]
2012-08-14 23:25     ` NeilBrown
2012-08-15  0:24     ` Sasha Levin
2012-08-15  0:24       ` Sasha Levin
2012-08-15  0:24       ` Sasha Levin
2012-08-15  0:28       ` Tejun Heo
2012-08-15  0:28         ` Tejun Heo
2012-08-14 16:24 ` [PATCH 02/16] user_ns: use new hashtable implementation Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 23:52   ` Eric W. Biederman
2012-08-14 23:52     ` Eric W. Biederman
2012-08-14 23:52     ` Eric W. Biederman
2012-08-15  0:47     ` Sasha Levin
2012-08-15  0:47       ` Sasha Levin
2012-08-15  0:47       ` Sasha Levin
2012-08-15  1:08       ` Eric W. Biederman
2012-08-15  1:08         ` Eric W. Biederman
2012-08-15  1:08         ` Eric W. Biederman
2012-08-15  1:35         ` Sasha Levin
2012-08-15  1:35           ` Sasha Levin
2012-08-15  3:13           ` Eric W. Biederman
2012-08-15  3:13             ` Eric W. Biederman
2012-08-15  3:13             ` Eric W. Biederman
2012-08-15  3:31             ` Mathieu Desnoyers
2012-08-15  3:31               ` Mathieu Desnoyers
2012-08-15 13:40               ` Sasha Levin
2012-08-15 13:40                 ` Sasha Levin
2012-08-15 13:40                 ` Sasha Levin
2012-08-15  8:46             ` David Laight
2012-08-15  8:46               ` David Laight
2012-08-15  8:46               ` David Laight
2012-08-16 14:28               ` Mathieu Desnoyers
2012-08-16 14:28                 ` Mathieu Desnoyers
2012-08-16 14:28                 ` Mathieu Desnoyers
2012-08-18 21:52     ` Sasha Levin
2012-08-18 22:21       ` Eric W. Biederman
2012-08-14 16:24 ` [PATCH 03/16] mm,ksm: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 04/16] workqueue: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 05/16] mm/huge_memory: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 06/16] tracepoint: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 07/16] net,9p: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 08/16] block,elevator: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` [PATCH 08/16] block, elevator: " Sasha Levin
2012-08-14 16:24 ` [PATCH 09/16] SUNRPC/cache: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 10/16] dlm: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 11/16] net,l2tp: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` [PATCH 11/16] net, l2tp: " Sasha Levin
2012-08-14 16:24 ` [PATCH 12/16] dm: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 13/16] lockd: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 14/16] net,rds: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 15/16] openvswitch: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24 ` [PATCH 16/16] tracing output: " Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 16:24   ` Sasha Levin
2012-08-14 18:16 ` [PATCH 00/16] generic " J. Bruce Fields
2012-08-14 18:16   ` J. Bruce Fields

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=20120815092523.00a909ef@notabene.brown \
    --to=neilb@suse.de \
    --cc=Trond.Myklebust@netapp.com \
    --cc=aarcange@redhat.com \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bfields@fieldses.org \
    --cc=ccaulfie@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=dm-devel@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=edumazet@google.com \
    --cc=ejt@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=ericvh@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=jesse@nicira.com \
    --cc=josh@joshtriplett.org \
    --cc=levinsasha928@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lw@cn.fujitsu.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=rds-devel@oss.oracle.com \
    --cc=rostedt@goodmis.org \
    --cc=snitzer@redhat.com \
    --cc=teigland@redhat.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=venkat.x.venkatsubra@oracle.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 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.