This hashtable implementation is using hlist buckets to provide a simple
hashtable to prevent it from getting reimplemented all over the kernel.
Signed-off-by: Sasha Levin <redacted>
---
Changes from v8:
- Addressed comments from Tejun Heo and Mathieu Desnoyers.
include/linux/hashtable.h | 196 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 196 insertions(+)
create mode 100644 include/linux/hashtable.h
--
1.7.12.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Switch to using the new hashtable implementation to store user structs.
This reduces the amount of generic unrelated code in kernel/user.c.
Signed-off-by: Sasha Levin <redacted>
---
kernel/user.c | 33 ++++++++++++---------------------
1 file changed, 12 insertions(+), 21 deletions(-)
Switch ksm to use the new hashtable implementation. This reduces the amount of
generic unrelated code in the ksm module.
Signed-off-by: Sasha Levin <redacted>
---
mm/ksm.c | 31 +++++++++++++------------------
1 file changed, 13 insertions(+), 18 deletions(-)
@@ -2038,6 +2032,7 @@ static int __init ksm_init(void)*/hotplug_memory_notifier(ksm_memory_callback,100);#endif+return0;out_free:
--
1.7.12.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Switch workqueues to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the workqueues.
Signed-off-by: Sasha Levin <redacted>
---
kernel/workqueue.c | 86 ++++++++++--------------------------------------------
1 file changed, 15 insertions(+), 71 deletions(-)
@@ -82,8 +83,6 @@ enum {NR_WORKER_POOLS=2,/* # worker pools per gcwq */BUSY_WORKER_HASH_ORDER=6,/* 64 pointers */-BUSY_WORKER_HASH_SIZE=1<<BUSY_WORKER_HASH_ORDER,-BUSY_WORKER_HASH_MASK=BUSY_WORKER_HASH_SIZE-1,MAX_IDLE_WORKERS_RATIO=4,/* 1/4 of busy can be idle */IDLE_WORKER_TIMEOUT=300*HZ,/* keep idle ones for 5 mins */
@@ -180,7 +179,7 @@ struct global_cwq {unsignedintflags;/* L: GCWQ_* flags *//* workers are chained either in busy_hash or pool idle_list */-structhlist_headbusy_hash[BUSY_WORKER_HASH_SIZE];+DECLARE_HASHTABLE(busy_hash,BUSY_WORKER_HASH_ORDER);/* L: hash of busy workers */structworker_poolpools[NR_WORKER_POOLS];
@@ -285,8 +284,7 @@ EXPORT_SYMBOL_GPL(system_freezable_wq);(pool)<&(gcwq)->pools[NR_WORKER_POOLS];(pool)++)#define for_each_busy_worker(worker, i, pos, gcwq) \-for(i=0;i<BUSY_WORKER_HASH_SIZE;i++)\-hlist_for_each_entry(worker,pos,&gcwq->busy_hash[i],hentry)+hash_for_each(gcwq->busy_hash,i,pos,worker,hentry)staticinlineint__next_gcwq_cpu(intcpu,conststructcpumask*mask,unsignedintsw)
@@ -857,63 +855,6 @@ static inline void worker_clr_flags(struct worker *worker, unsigned int flags)}/**-*busy_worker_head-returnthebusyhashheadforawork-*@gcwq:gcwqofinterest-*@work:worktobehashed-*-*Returnhashheadof@gcwqfor@work.-*-*CONTEXT:-*spin_lock_irq(gcwq->lock).-*-*RETURNS:-*Pointertothehashhead.-*/-staticstructhlist_head*busy_worker_head(structglobal_cwq*gcwq,-structwork_struct*work)-{-constintbase_shift=ilog2(sizeof(structwork_struct));-unsignedlongv=(unsignedlong)work;--/* simple shift and fold hash, do we need something better? */-v>>=base_shift;-v+=v>>BUSY_WORKER_HASH_ORDER;-v&=BUSY_WORKER_HASH_MASK;--return&gcwq->busy_hash[v];-}--/**-*__find_worker_executing_work-findworkerwhichisexecutingawork-*@gcwq:gcwqofinterest-*@bwh:hashheadasreturnedbybusy_worker_head()-*@work:worktofindworkerfor-*-*Findaworkerwhichisexecuting@workon@gcwq.@bwhshouldbe-*thehashheadobtainedbycallingbusy_worker_head()withthesame-*work.-*-*CONTEXT:-*spin_lock_irq(gcwq->lock).-*-*RETURNS:-*Pointertoworkerwhichisexecuting@workiffound,NULL-*otherwise.-*/-staticstructworker*__find_worker_executing_work(structglobal_cwq*gcwq,-structhlist_head*bwh,-structwork_struct*work)-{-structworker*worker;-structhlist_node*tmp;--hlist_for_each_entry(worker,tmp,bwh,hentry)-if(worker->current_work==work)-returnworker;-returnNULL;-}--/***find_worker_executing_work-findworkerwhichisexecutingawork*@gcwq:gcwqofinterest*@work:worktofindworkerfor
@@ -3823,7 +3769,6 @@ out_unlock:staticint__initinit_workqueues(void){unsignedintcpu;-inti;/* make sure we have enough bits for OFFQ CPU number */BUILD_BUG_ON((1LU<<(BITS_PER_LONG-WORK_OFFQ_CPU_SHIFT))<
@@ -3841,8 +3786,7 @@ static int __init init_workqueues(void)gcwq->cpu=cpu;gcwq->flags|=GCWQ_DISASSOCIATED;-for(i=0;i<BUSY_WORKER_HASH_SIZE;i++)-INIT_HLIST_HEAD(&gcwq->busy_hash[i]);+hash_init(gcwq->busy_hash);for_each_worker_pool(pool,gcwq){pool->gcwq=gcwq;
Switch tracepoints to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the tracepoints.
Signed-off-by: Sasha Levin <redacted>
---
kernel/tracepoint.c | 25 +++++++++----------------
1 file changed, 9 insertions(+), 16 deletions(-)
Switch 9p error table to use the new hashtable implementation. This reduces
the amount of generic unrelated code in 9p.
Signed-off-by: Sasha Levin <redacted>
---
net/9p/error.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
@@ -223,13 +220,13 @@ int p9_errstr2errno(char *errstr, int len)interrno;structhlist_node*p;structerrormap*c;-intbucket;+u32hash;errno=0;p=NULL;c=NULL;-bucket=jhash(errstr,len,0)%ERRHASHSZ;-hlist_for_each_entry(c,p,&hash_errmap[bucket],list){+hash=jhash(errstr,len,0);+hash_for_each_possible(hash_errmap,c,p,list,hash){if(c->namelen==len&&!memcmp(c->name,errstr,len)){errno=c->val;break;
Switch elevator to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the elevator.
This also removes the dymanic allocation of the hash table. The size of the table is
constant so there's no point in paying the price of an extra dereference when accessing
it.
Signed-off-by: Sasha Levin <redacted>
---
block/blk.h | 2 +-
block/elevator.c | 23 ++++-------------------
include/linux/elevator.h | 5 ++++-
3 files changed, 9 insertions(+), 21 deletions(-)
Switch cache to use the new hashtable implementation. This reduces the amount
of generic unrelated code in the cache implementation.
Signed-off-by: Sasha Levin <redacted>
---
net/sunrpc/cache.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
--
1.7.12.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Switch dlm to use the new hashtable implementation. This reduces the amount of
generic unrelated code in the dlm.
Signed-off-by: Sasha Levin <redacted>
---
fs/dlm/lowcomms.c | 53 ++++++++++++++++++-----------------------------------
1 file changed, 18 insertions(+), 35 deletions(-)
@@ -62,7 +63,7 @@#include"config.h"#define NEEDED_RMEM (4*1024*1024)-#define CONN_HASH_SIZE 32+#define CONN_HASH_BITS 5/* Number of messages to send before rescheduling */#define MAX_SEND_MSG_COUNT 25
@@ -158,34 +159,27 @@ static int dlm_allow_conn;staticstructworkqueue_struct*recv_workqueue;staticstructworkqueue_struct*send_workqueue;-staticstructhlist_headconnection_hash[CONN_HASH_SIZE];+/*+*Onasidenote,hashfunctioncouldbeverysimplebecausemostclusters+*havesimplesequentialnodeids,soweshouldbeabletogostraightto+*aconnectionstructinthearray.Wedon'tutilizeitatthemoment,+*butit'ssomethingworktokeepinmind.+*/+staticDEFINE_HASHTABLE(connection_hash,CONN_HASH_BITS);staticDEFINE_MUTEX(connections_lock);staticstructkmem_cache*con_cache;staticvoidprocess_recv_sockets(structwork_struct*work);staticvoidprocess_send_sockets(structwork_struct*work);--/* This is deliberately very simple because most clusters have simple-sequentialnodeids,soweshouldbeabletogostraighttoaconnection-structinthearray*/-staticinlineintnodeid_hash(intnodeid)-{-returnnodeid&(CONN_HASH_SIZE-1);-}-staticstructconnection*__find_con(intnodeid){-intr;structhlist_node*h;structconnection*con;-r=nodeid_hash(nodeid);--hlist_for_each_entry(con,h,&connection_hash[r],list){+hash_for_each_possible(connection_hash,con,h,list,nodeid)if(con->nodeid==nodeid)returncon;-}returnNULL;}
@@ -107,8 +108,14 @@ static unsigned int l2tp_net_id;structl2tp_net{structlist_headl2tp_tunnel_list;spinlock_tl2tp_tunnel_list_lock;-structhlist_headl2tp_session_hlist[L2TP_HASH_SIZE_2];-spinlock_tl2tp_session_hlist_lock;+/*+*SessionhashgloballistforL2TPv3.+*Thesession_idSHOULDberandomaccordingtoRFC3931,butseveral+*L2TPimplementationsuseincrementingsession_ids.Sowedoareal+*hashonthesession_id,ratherthanasimplebitmask.+*/+DECLARE_HASHTABLE(l2tp_session_hash,L2TP_HASH_BITS_2);+spinlock_tl2tp_session_hash_lock;};staticvoidl2tp_session_set_header_len(structl2tp_session*session,intversion);
@@ -156,30 +163,17 @@ do { \#define l2tp_tunnel_dec_refcount(t) l2tp_tunnel_dec_refcount_1(t)#endif-/* Session hash global list for L2TPv3.-*Thesession_idSHOULDberandomaccordingtoRFC3931,butseveral-*L2TPimplementationsuseincrementingsession_ids.Sowedoareal-*hashonthesession_id,ratherthanasimplebitmask.-*/-staticinlinestructhlist_head*-l2tp_session_id_hash_2(structl2tp_net*pn,u32session_id)-{-return&pn->l2tp_session_hlist[hash_32(session_id,L2TP_HASH_BITS_2)];--}-/* Lookup a session by id in the global session list*/staticstructl2tp_session*l2tp_session_find_2(structnet*net,u32session_id){structl2tp_net*pn=l2tp_pernet(net);-structhlist_head*session_list=-l2tp_session_id_hash_2(pn,session_id);structl2tp_session*session;structhlist_node*walk;rcu_read_lock_bh();-hlist_for_each_entry_rcu(session,walk,session_list,global_hlist){+hash_for_each_possible_rcu(pn->l2tp_session_hash,session,walk,+global_hlist,session_id){if(session->session_id==session_id){rcu_read_unlock_bh();returnsession;
@@ -190,23 +184,10 @@ static struct l2tp_session *l2tp_session_find_2(struct net *net, u32 session_id)returnNULL;}-/* Session hash list.-*Thesession_idSHOULDberandomaccordingtoRFC2661,butseveral-*L2TPimplementations(CiscoandMicrosoft)useincrementing-*session_ids.Sowedoarealhashonthesession_id,ratherthana-*simplebitmask.-*/-staticinlinestructhlist_head*-l2tp_session_id_hash(structl2tp_tunnel*tunnel,u32session_id)-{-return&tunnel->session_hlist[hash_32(session_id,L2TP_HASH_BITS)];-}-/* Lookup a session by id*/structl2tp_session*l2tp_session_find(structnet*net,structl2tp_tunnel*tunnel,u32session_id){-structhlist_head*session_list;structl2tp_session*session;structhlist_node*walk;
@@ -1282,16 +1258,14 @@ static void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel)l2tp_info(tunnel,L2TP_MSG_CONTROL,"%s: closing all sessions...\n",tunnel->name);-write_lock_bh(&tunnel->hlist_lock);-for(hash=0;hash<L2TP_HASH_SIZE;hash++){-again:-hlist_for_each_safe(walk,tmp,&tunnel->session_hlist[hash]){-session=hlist_entry(walk,structl2tp_session,hlist);-+write_lock_bh(&tunnel->hash_lock);+do{+found=0;+hash_for_each_safe(tunnel->session_hash,hash,walk,tmp,session,hlist){l2tp_info(session,L2TP_MSG_CONTROL,"%s: closing session\n",session->name);-hlist_del_init(&session->hlist);+hash_del(&session->hlist);/* Since we should hold the sock lock while*doinganyunbinding,weneedtoreleasethe
@@ -1319,17 +1293,17 @@ again:if(session->deref!=NULL)(*session->deref)(session);-write_lock_bh(&tunnel->hlist_lock);+write_lock_bh(&tunnel->hash_lock);/* Now restart from the beginning of this hash*chain.Wealwaysremoveasessionfromthe*listsoweareguaranteedtomakeforward*progress.*/-gotoagain;+found=1;}-}-write_unlock_bh(&tunnel->hlist_lock);+}while(found);+write_unlock_bh(&tunnel->hash_lock);}/* Really kill the tunnel.
@@ -1576,7 +1550,7 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32tunnel->magic=L2TP_TUNNEL_MAGIC;sprintf(&tunnel->name[0],"tunl %u",tunnel_id);-rwlock_init(&tunnel->hlist_lock);+rwlock_init(&tunnel->hash_lock);/* The net we belong to */tunnel->l2tp_net=net;
@@ -1613,6 +1587,8 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32/* Add tunnel to our list */INIT_LIST_HEAD(&tunnel->list);++hash_init(tunnel->session_hash);atomic_inc(&l2tp_tunnel_count);/* Bump the reference count. The tunnel context is deleted
@@ -1677,17 +1653,17 @@ void l2tp_session_free(struct l2tp_session *session)BUG_ON(tunnel->magic!=L2TP_TUNNEL_MAGIC);/* Delete the session from the hash */-write_lock_bh(&tunnel->hlist_lock);-hlist_del_init(&session->hlist);-write_unlock_bh(&tunnel->hlist_lock);+write_lock_bh(&tunnel->hash_lock);+hash_del(&session->hlist);+write_unlock_bh(&tunnel->hash_lock);/* Unlink from the global hash if not L2TPv2 */if(tunnel->version!=L2TP_HDR_VER_2){structl2tp_net*pn=l2tp_pernet(tunnel->l2tp_net);-spin_lock_bh(&pn->l2tp_session_hlist_lock);-hlist_del_init_rcu(&session->global_hlist);-spin_unlock_bh(&pn->l2tp_session_hlist_lock);+spin_lock_bh(&pn->l2tp_session_hash_lock);+hash_del_rcu(&session->global_hlist);+spin_unlock_bh(&pn->l2tp_session_hash_lock);synchronize_rcu();}
@@ -1800,19 +1776,17 @@ struct l2tp_session *l2tp_session_create(int priv_size, struct l2tp_tunnel *tunnsock_hold(tunnel->sock);/* Add session to the tunnel's hash list */-write_lock_bh(&tunnel->hlist_lock);-hlist_add_head(&session->hlist,-l2tp_session_id_hash(tunnel,session_id));-write_unlock_bh(&tunnel->hlist_lock);+write_lock_bh(&tunnel->hash_lock);+hash_add(tunnel->session_hash,&session->hlist,session_id);+write_unlock_bh(&tunnel->hash_lock);/* And to the global session list if L2TPv3 */if(tunnel->version!=L2TP_HDR_VER_2){structl2tp_net*pn=l2tp_pernet(tunnel->l2tp_net);-spin_lock_bh(&pn->l2tp_session_hlist_lock);-hlist_add_head_rcu(&session->global_hlist,-l2tp_session_id_hash_2(pn,session_id));-spin_unlock_bh(&pn->l2tp_session_hlist_lock);+spin_lock_bh(&pn->l2tp_session_hash_lock);+hash_add(pn->l2tp_session_hash,&session->global_hlist,session_id);+spin_unlock_bh(&pn->l2tp_session_hash_lock);}/* Ignore management session in session count value */
@@ -80,7 +78,7 @@ struct dm_snapshot {/* Chunks with outstanding reads */spinlock_ttracked_chunk_lock;mempool_t*tracked_chunk_pool;-structhlist_headtracked_chunk_hash[DM_TRACKED_CHUNK_HASH_SIZE];+DECLARE_HASHTABLE(tracked_chunk_hash,DM_TRACKED_CHUNK_HASH_BITS);/* The on disk metadata handler */structdm_exception_store*store;
Switch rds to use the new hashtable implementation. This reduces the amount of
generic unrelated code in rds.
Signed-off-by: Sasha Levin <redacted>
---
net/rds/bind.c | 20 +++++------
net/rds/connection.c | 100 ++++++++++++++++++++++-----------------------------
2 files changed, 53 insertions(+), 67 deletions(-)
@@ -34,28 +34,24 @@#include<linux/list.h>#include<linux/slab.h>#include<linux/export.h>+#include<linux/hashtable.h>#include<net/inet_hashtables.h>#include"rds.h"#include"loop.h"#define RDS_CONNECTION_HASH_BITS 12-#define RDS_CONNECTION_HASH_ENTRIES (1 << RDS_CONNECTION_HASH_BITS)-#define RDS_CONNECTION_HASH_MASK (RDS_CONNECTION_HASH_ENTRIES - 1)/* converting this to RCU is a chore for another day.. */staticDEFINE_SPINLOCK(rds_conn_lock);staticunsignedlongrds_conn_count;-staticstructhlist_headrds_conn_hash[RDS_CONNECTION_HASH_ENTRIES];+staticDEFINE_HASHTABLE(rds_conn_hash,RDS_CONNECTION_HASH_BITS);staticstructkmem_cache*rds_conn_slab;-staticstructhlist_head*rds_conn_bucket(__be32laddr,__be32faddr)+staticunsignedlongrds_conn_hashfn(__be32laddr,__be32faddr){/* Pass NULL, don't need struct net for hash */-unsignedlonghash=inet_ehashfn(NULL,-be32_to_cpu(laddr),0,-be32_to_cpu(faddr),0);-return&rds_conn_hash[hash&RDS_CONNECTION_HASH_MASK];+returninet_ehashfn(NULL,be32_to_cpu(laddr),0,be32_to_cpu(faddr),0);}#define rds_conn_info_set(var, test, suffix) do { \
@@ -64,14 +60,14 @@ static struct hlist_head *rds_conn_bucket(__be32 laddr, __be32 faddr)}while(0)/* rcu read lock must be held or the connection spinlock */-staticstructrds_connection*rds_conn_lookup(structhlist_head*head,-__be32laddr,__be32faddr,+staticstructrds_connection*rds_conn_lookup(__be32laddr,__be32faddr,structrds_transport*trans){structrds_connection*conn,*ret=NULL;structhlist_node*pos;+unsignedlongkey=rds_conn_hashfn(laddr,faddr);-hlist_for_each_entry_rcu(conn,pos,head,c_hash_node){+hash_for_each_possible_rcu(rds_conn_hash,conn,pos,c_hash_node,key){if(conn->c_faddr==faddr&&conn->c_laddr==laddr&&conn->c_trans==trans){ret=conn;
@@ -117,13 +113,12 @@ static struct rds_connection *__rds_conn_create(__be32 laddr, __be32 faddr,intis_outgoing){structrds_connection*conn,*parent=NULL;-structhlist_head*head=rds_conn_bucket(laddr,faddr);structrds_transport*loop_trans;unsignedlongflags;intret;rcu_read_lock();-conn=rds_conn_lookup(head,laddr,faddr,trans);+conn=rds_conn_lookup(laddr,faddr,trans);if(conn&&conn->c_loopback&&conn->c_trans!=&rds_loop_transport&&!is_outgoing){/* This is a looped back IB connection, and we're
@@ -329,7 +326,7 @@ void rds_conn_destroy(struct rds_connection *conn)/* Ensure conn will not be scheduled for reconnect */spin_lock_irq(&rds_conn_lock);-hlist_del_init_rcu(&conn->c_hash_node);+hash_del(&conn->c_hash_node);spin_unlock_irq(&rds_conn_lock);synchronize_rcu();
@@ -448,23 +440,19 @@ void rds_for_each_conn_info(struct socket *sock, unsigned int len,lens->nr=0;lens->each=item_len;-for(i=0,head=rds_conn_hash;i<ARRAY_SIZE(rds_conn_hash);-i++,head++){-hlist_for_each_entry_rcu(conn,pos,head,c_hash_node){--/* XXX no c_lock usage.. */-if(!visitor(conn,buffer))-continue;--/* We copy as much as we can fit in the buffer,-*butwecountallitemssothatthecaller-*canresizethebuffer.*/-if(len>=item_len){-rds_info_copy(iter,buffer,item_len);-len-=item_len;-}-lens->nr++;+hash_for_each_rcu(rds_conn_hash,i,pos,conn,c_hash_node){+/* XXX no c_lock usage.. */+if(!visitor(conn,buffer))+continue;++/* We copy as much as we can fit in the buffer,+*butwecountallitemssothatthecaller+*canresizethebuffer.*/+if(len>=item_len){+rds_info_copy(iter,buffer,item_len);+len-=item_len;}+lens->nr++;}rcu_read_unlock();}
Switch tracing to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the tracing module.
Signed-off-by: Sasha Levin <redacted>
---
kernel/trace/trace_output.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
@@ -8,15 +8,15 @@#include<linux/module.h>#include<linux/mutex.h>#include<linux/ftrace.h>+#include<linux/hashtable.h>#include"trace_output.h"-/* must be a power of 2 */-#define EVENT_HASHSIZE 128+#define EVENT_HASH_BITS 7DECLARE_RWSEM(trace_event_mutex);-staticstructhlist_headevent_hash[EVENT_HASHSIZE]__read_mostly;+staticDEFINE_HASHTABLE(event_hash,EVENT_HASH_BITS);staticintnext_event_type=__TRACE_LAST_TYPE+1;
Switch openvswitch to use the new hashtable implementation. This reduces the
amount of generic unrelated code in openvswitch.
Signed-off-by: Sasha Levin <redacted>
---
net/openvswitch/vport.c | 35 ++++++++++++-----------------------
1 file changed, 12 insertions(+), 23 deletions(-)
Switch lockd to use the new hashtable implementation. This reduces the amount
of generic unrelated code in lockd.
Signed-off-by: Sasha Levin <redacted>
---
fs/lockd/svcsubs.c | 58 ++++++++++++++++++++++++++----------------------------
1 file changed, 28 insertions(+), 30 deletions(-)
@@ -253,27 +253,25 @@ nlm_traverse_files(void *data, nlm_host_match_fn_t match,inti,ret=0;mutex_lock(&nlm_file_mutex);-for(i=0;i<FILE_NRHASH;i++){-hlist_for_each_entry_safe(file,pos,next,&nlm_files[i],f_list){-if(is_failover_file&&!is_failover_file(data,file))-continue;-file->f_count++;-mutex_unlock(&nlm_file_mutex);--/* Traverse locks, blocks and shares of this file-*andupdatefile->f_lockscount*/-if(nlm_inspect_file(data,file,match))-ret=1;--mutex_lock(&nlm_file_mutex);-file->f_count--;-/* No more references to this file. Let go of it. */-if(list_empty(&file->f_blocks)&&!file->f_locks-&&!file->f_shares&&!file->f_count){-hlist_del(&file->f_list);-nlmsvc_ops->fclose(file->f_file);-kfree(file);-}+hash_for_each_safe(nlm_files,i,pos,next,file,f_list){+if(is_failover_file&&!is_failover_file(data,file))+continue;+file->f_count++;+mutex_unlock(&nlm_file_mutex);++/* Traverse locks, blocks and shares of this file+*andupdatefile->f_lockscount*/+if(nlm_inspect_file(data,file,match))+ret=1;++mutex_lock(&nlm_file_mutex);+file->f_count--;+/* No more references to this file. Let go of it. */+if(list_empty(&file->f_blocks)&&!file->f_locks+&&!file->f_shares&&!file->f_count){+hash_del(&file->f_list);+nlmsvc_ops->fclose(file->f_file);+kfree(file);}}mutex_unlock(&nlm_file_mutex);
Switch hugemem to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the hugemem.
This also removes the dymanic allocation of the hash table. The size of the table is
constant so there's no point in paying the price of an extra dereference when accessing
it.
Signed-off-by: Sasha Levin <redacted>
---
mm/huge_memory.c | 53 ++++++++++++-----------------------------------------
1 file changed, 12 insertions(+), 41 deletions(-)
--
1.7.12.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
This hashtable implementation is using hlist buckets to provide a simple
hashtable to prevent it from getting reimplemented all over the kernel.
Signed-off-by: Sasha Levin <redacted>
Switch tracepoints to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the tracepoints.
Signed-off-by: Sasha Levin <redacted>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Steven Rostedt <rostedt@goodmis.org> Date: 2012-10-30 19:23:52
On Tue, 2012-10-30 at 14:46 -0400, Sasha Levin wrote:
Switch tracing to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the tracing module.
Signed-off-by: Sasha Levin <redacted>
Hello,
Just some nitpicks.
On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
quoted hunk
+/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */+#define hash_min(val, bits) \+({ \+ sizeof(val) <= 4 ? \+ hash_32(val, bits) : \+ hash_long(val, bits); \+})
Doesn't the above fit in 80 column. Why is it broken into multiple
lines? Also, you probably want () around at least @val. In general,
it's a good idea to add () around any macro argument to avoid nasty
surprises.
Looks good to me otherwise.
Reviewed-by: Tejun Heo [off-list ref]
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo [off-list ref] wrote:
Hello,
Just some nitpicks.
On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
quoted
+/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */+#define hash_min(val, bits) \+({ \+ sizeof(val) <= 4 ? \+ hash_32(val, bits) : \+ hash_long(val, bits); \+})
Doesn't the above fit in 80 column. Why is it broken into multiple
lines? Also, you probably want () around at least @val. In general,
it's a good idea to add () around any macro argument to avoid nasty
surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
Thanks,
Sasha
Looks good to me otherwise.
Reviewed-by: Tejun Heo [off-list ref]
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Sasha Levin wrote:
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo [off-list ref] wrote:
> Hello,
>
> Just some nitpicks.
>
> On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
>> +#define hash_min(val, bits) \
>> +({ \
>> + sizeof(val) <= 4 ? \
>> + hash_32(val, bits) : \
>> + hash_long(val, bits); \
>> +})
>
> Doesn't the above fit in 80 column. Why is it broken into multiple
> lines? Also, you probably want () around at least @val. In general,
> it's a good idea to add () around any macro argument to avoid nasty
> surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
I would prefer the body be all on one line too. But shouldn't this be a
static inline function?
On Tue, Oct 30, 2012 at 8:51 PM, Jim Rees [off-list ref] wrote:
Sasha Levin wrote:
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo [off-list ref] wrote:
> Hello,
>
> Just some nitpicks.
>
> On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
>> +#define hash_min(val, bits) \
>> +({ \
>> + sizeof(val) <= 4 ? \
>> + hash_32(val, bits) : \
>> + hash_long(val, bits); \
>> +})
>
> Doesn't the above fit in 80 column. Why is it broken into multiple
> lines? Also, you probably want () around at least @val. In general,
> it's a good idea to add () around any macro argument to avoid nasty
> surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
I would prefer the body be all on one line too. But shouldn't this be a
static inline function?
We want sizeof(val), which wouldn't work in a static inline. We can
either wrap a static inline __hash_min() with a macro and pass that
size to it, but that's quite an overkill here, or we can add a size
parameter to hash_min(), but it would look awkward considering how
hash_32()/hash_64()/hash_long() look like.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Steven Rostedt <rostedt@goodmis.org> Date: 2012-10-31 01:16:33
On Tue, 2012-10-30 at 20:33 -0400, Sasha Levin wrote:
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo [off-list ref] wrote:
quoted
Hello,
Just some nitpicks.
On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
quoted
+/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */+#define hash_min(val, bits) \+({ \+ sizeof(val) <= 4 ? \+ hash_32(val, bits) : \+ hash_long(val, bits); \+})
Doesn't the above fit in 80 column. Why is it broken into multiple
lines? Also, you probably want () around at least @val. In general,
it's a good idea to add () around any macro argument to avoid nasty
surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
({ \
sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
})
Is the better way to go. We are C programmers, we like to see the ?: on
a single line if possible. The way you have it, looks like three
statements run consecutively.
-- Steve
On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt [off-list ref] wrote:
({ \
sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
})
Is the better way to go. We are C programmers, we like to see the ?: on
a single line if possible. The way you have it, looks like three
statements run consecutively.
If we're C programmers, why use the non-standard statement-expression
at all? And split it onto three lines when it's just a single one?
But whatever. This series has gotten way too much bike-shedding
anyway. I think it should just be applied, since it does remove lines
of code overall. I'd even possibly apply it to mainline, but it seems
to be against linux-next.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Steven Rostedt <rostedt@goodmis.org> Date: 2012-10-31 01:36:37
On Tue, 2012-10-30 at 18:25 -0700, Linus Torvalds wrote:
On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt [off-list ref] wrote:
quoted
({ \
sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
})
Is the better way to go. We are C programmers, we like to see the ?: on
a single line if possible. The way you have it, looks like three
statements run consecutively.
If we're C programmers, why use the non-standard statement-expression
at all? And split it onto three lines when it's just a single one?
I like the blue color over the pink. Anyway, I was just expressing an
opinion and really didn't care if it was changed or not.
But whatever. This series has gotten way too much bike-shedding
anyway. I think it should just be applied, since it does remove lines
of code overall. I'd even possibly apply it to mainline, but it seems
to be against linux-next.
I would think this change is a bit too big for an -rc4 release, but
you're the boss. I've already given my ack for my code that this set
touches. Let it go to Stephen's repo then.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
But whatever. This series has gotten way too much bike-shedding
anyway. I think it should just be applied, since it does remove lines
of code overall. I'd even possibly apply it to mainline, but it seems
to be against linux-next.
Yup, I switched to using -next because I've been running my
trinity/KVM tools tests with it.
I can either rebase that on top of mainline, or we can ask maintainers
to take it to their own trees if you take only 01/16 into mainline.
What would you prefer?
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
On Tue, Oct 30, 2012 at 6:36 PM, Sasha Levin [off-list ref] wrote:
I can either rebase that on top of mainline, or we can ask maintainers
to take it to their own trees if you take only 01/16 into mainline.
What would you prefer?
I don't really care deeply. The only reason to merge it now would be
to avoid any pain with it during the next merge window. Just taking
01/16 might be the sanest way to do that, then the rest can trickle in
independently at their own leisure.
Linus
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2012-10-31 02:24:39
On Tue, Oct 30, 2012 at 06:25:46PM -0700, Linus Torvalds wrote:
But whatever. This series has gotten way too much bike-shedding
anyway. I think it should just be applied, since it does remove lines
of code overall. I'd even possibly apply it to mainline, but it seems
to be against linux-next.
BTW, how serious have you been back at KS when you were talking about
pull requests killing a thousand of lines of code being acceptable
at any point in the cycle? Because right now I'm sitting on a pile that
removes 2-3 times as much (~-2KLoC for stuff that got considerable
testing for most of the architectures, -3KLoC if I include fork/clone/vfork
unification series) and seeing how maintainers of a bunch of embedded
architectures seem to be MIA... The idea of saying "screw them" and sending
a pull request becomes more and more tempting every day ;-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
On Tue, Oct 30, 2012 at 7:24 PM, Al Viro [off-list ref] wrote:
BTW, how serious have you been back at KS when you were talking about
pull requests killing a thousand of lines of code being acceptable
at any point in the cycle?
Well... I'm absolutely a lot more open to pull requests that kill code
than not, but I have to admit to being a bit more worried about stuff
like your execve/fork patches that touch very low-level code.
So I think I'll punt that for 3.8 anyway.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2012-10-31 03:24:46
On Tue, Oct 30, 2012 at 07:48:19PM -0700, Linus Torvalds wrote:
On Tue, Oct 30, 2012 at 7:24 PM, Al Viro [off-list ref] wrote:
quoted
BTW, how serious have you been back at KS when you were talking about
pull requests killing a thousand of lines of code being acceptable
at any point in the cycle?
Well... I'm absolutely a lot more open to pull requests that kill code
than not, but I have to admit to being a bit more worried about stuff
like your execve/fork patches that touch very low-level code.
So I think I'll punt that for 3.8 anyway.
Oh, well... there go my blackmail plans ;-) Seriously, though, I'm at loss
regarding several embedded architectures - arch/score, in particular,
seems to be completely orphaned. As far as I can see, it's
* abandoned by hw vendor (seems like they were planning to push
it game consoles, but that was just before the recession, and...)
* abandoned by primary maintainer, who isn't employed by said
hw vendor anymore, so his old address had been bouncy for several years.
He had bothered to update it in gcc tree, but hadn't been active there
either for almost as long. And new address in gcc tree is of form
<name>+gcc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, so using it for kernel-related mail would seem to
be a lousy idea.
* the second maintainer seems to be nearly MIA as well - all I can
find is Acked-by on one commit. Cc'ed on the kernel_execve() thread, but...
no signs of life whatsoever.
* a lot of asm glue is in "apparently never worked" state, starting
with ptrace hookup (it's clearly started its life as a mips clone, but uses
different registers for passing return value, etc. TIF_SYSCALL_TRACE side of
that thing still assumes MIPS ABI *and* is suffering obvious bitrot)
Sigh...
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 30, 2012 at 8:24 PM, Al Viro [off-list ref] wrote:
Oh, well... there go my blackmail plans ;-) Seriously, though, I'm at loss
regarding several embedded architectures - arch/score, in particular,
seems to be completely orphaned.
Don't worry about it. Do a best-effort, and if nobody ever reacts
about some odd-ball architecture, whatever.
We won't start deleting architectures over something like this, but it
might be another sign down the road that some arch code can be removed
entirely.
So it's not arch/score I'd worry about. It's all the *other* architectures..
Linus
From: David Laight <hidden> Date: 2012-10-31 09:57:55
quoted
quoted
On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
quoted
+/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */+#define hash_min(val, bits) \+({ \+ sizeof(val) <= 4 ? \+ hash_32(val, bits) : \+ hash_long(val, bits); \+})
Doesn't the above fit in 80 column. Why is it broken into multiple
lines? Also, you probably want () around at least @val. In general,
it's a good idea to add () around any macro argument to avoid nasty
surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
({ \
sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
})
Is the better way to go. We are C programmers, we like to see the ?: on
a single line if possible. The way you have it, looks like three
statements run consecutively.
To add some more colour (not color):
In any case, this is a normal C #define, it doesn't need the {}.
So it can just be:
# define hash_min(val, bits) \
(sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits))
I don't think that s/val/(val)/g and s/bits/(bits)/g are needed
because the tokens are already ',' separated.
I do actually wonder how many of these hash lists should be replaced
with some kind of tree structure in order to get O(log(n)) searches.
After all hashing is still O(n).
(apologies if I mean o(n) not O(n) - it's a long time since I did
my maths degree!)
David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
On Tue, Oct 30, 2012 at 10:23 PM, Linus Torvalds
[off-list ref] wrote:
On Tue, Oct 30, 2012 at 6:36 PM, Sasha Levin [off-list ref] wrote:
quoted
I can either rebase that on top of mainline, or we can ask maintainers
to take it to their own trees if you take only 01/16 into mainline.
What would you prefer?
I don't really care deeply. The only reason to merge it now would be
to avoid any pain with it during the next merge window. Just taking
01/16 might be the sanest way to do that, then the rest can trickle in
independently at their own leisure.
Okay, I'll keep working on converting everything else as soon as 01/16
makes it in your tree.
Thanks,
Sasha