* PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long....
@ 2002-08-20 4:24 Neil Brown
2002-08-20 22:53 ` Benjamin LaHaise
0 siblings, 1 reply; 6+ messages in thread
From: Neil Brown @ 2002-08-20 4:24 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: nfs
As Dave Miller reminded me, 'flags' fields must be unsigned long.
----------- Diffstat output ------------
./include/linux/sunrpc/svcsock.h | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- ./include/linux/sunrpc/svcsock.h 2002/08/20 03:00:47 1.1
+++ ./include/linux/sunrpc/svcsock.h 2002/08/20 03:01:25 1.2
@@ -22,7 +22,7 @@ struct svc_sock {
struct svc_serv * sk_server; /* service for this socket */
unsigned char sk_inuse; /* use count */
- unsigned int sk_flags;
+ unsigned long sk_flags;
#define SK_BUSY 0 /* enqueued/receiving */
#define SK_CONN 1 /* conn pending */
#define SK_CLOSE 2 /* dead or dying */
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long....
2002-08-20 4:24 PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long Neil Brown
@ 2002-08-20 22:53 ` Benjamin LaHaise
2002-08-20 23:16 ` Trond Myklebust
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin LaHaise @ 2002-08-20 22:53 UTC (permalink / raw)
To: Neil Brown; +Cc: Marcelo Tosatti, nfs
On Tue, Aug 20, 2002 at 02:24:56PM +1000, Neil Brown wrote:
> @@ -22,7 +22,7 @@ struct svc_sock {
>
> struct svc_serv * sk_server; /* service for this socket */
> unsigned char sk_inuse; /* use count */
> - unsigned int sk_flags;
> + unsigned long sk_flags;
Cool, 7 bytes of useless padding on 64 bit architectures.
-ben
--
"You will be reincarnated as a toad; and you will be much happier."
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long....
2002-08-20 22:53 ` Benjamin LaHaise
@ 2002-08-20 23:16 ` Trond Myklebust
2002-08-20 23:21 ` Benjamin LaHaise
0 siblings, 1 reply; 6+ messages in thread
From: Trond Myklebust @ 2002-08-20 23:16 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: nfs
>>>>> " " == Benjamin LaHaise <bcrl@redhat.com> writes:
> On Tue, Aug 20, 2002 at 02:24:56PM +1000, Neil Brown wrote:
>> @@ -22,7 +22,7 @@ struct svc_sock {
>>
>> struct svc_serv * sk_server; /* service for this socket */
>> unsigned char sk_inuse; /* use count */
>> - unsigned int sk_flags;
>> + unsigned long sk_flags;
> Cool, 7 bytes of useless padding on 64 bit architectures.
All down to the sad inability of certain 64-bit "processor architects"
to provide for atomic bit operations on 32-bit integers.
If the relatively minor bloat in knfsd worries you, then I advise you
to take a deep breath before peeking at struct page... 8-)
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long....
2002-08-20 23:16 ` Trond Myklebust
@ 2002-08-20 23:21 ` Benjamin LaHaise
2002-08-20 23:32 ` Neil Brown
2002-08-20 23:44 ` Trond Myklebust
0 siblings, 2 replies; 6+ messages in thread
From: Benjamin LaHaise @ 2002-08-20 23:21 UTC (permalink / raw)
To: Trond Myklebust; +Cc: nfs
On Wed, Aug 21, 2002 at 01:16:12AM +0200, Trond Myklebust wrote:
> > On Tue, Aug 20, 2002 at 02:24:56PM +1000, Neil Brown wrote:
> >> @@ -22,7 +22,7 @@ struct svc_sock {
> >>
> >> struct svc_serv * sk_server; /* service for this socket */
> >> unsigned char sk_inuse; /* use count */
> >> - unsigned int sk_flags;
> >> + unsigned long sk_flags;
>
> > Cool, 7 bytes of useless padding on 64 bit architectures.
>
> All down to the sad inability of certain 64-bit "processor architects"
> to provide for atomic bit operations on 32-bit integers.
> If the relatively minor bloat in knfsd worries you, then I advise you
> to take a deep breath before peeking at struct page... 8-)
You've missed the point. Between sk_inuse and sk_flags is 7 bytes of
padding. Yes, I'm aware that sk_flags has 7 bytes of unused space, but
that's the unavoidable part. Personally, I think the sunrpc code should
do this particular operation differently.
-ben
--
"You will be reincarnated as a toad; and you will be much happier."
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long....
2002-08-20 23:21 ` Benjamin LaHaise
@ 2002-08-20 23:32 ` Neil Brown
2002-08-20 23:44 ` Trond Myklebust
1 sibling, 0 replies; 6+ messages in thread
From: Neil Brown @ 2002-08-20 23:32 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Trond Myklebust, nfs
On Tuesday August 20, bcrl@redhat.com wrote:
> On Wed, Aug 21, 2002 at 01:16:12AM +0200, Trond Myklebust wrote:
> > > On Tue, Aug 20, 2002 at 02:24:56PM +1000, Neil Brown wrote:
> > >> @@ -22,7 +22,7 @@ struct svc_sock {
> > >>
> > >> struct svc_serv * sk_server; /* service for this socket */
> > >> unsigned char sk_inuse; /* use count */
> > >> - unsigned int sk_flags;
> > >> + unsigned long sk_flags;
> >
> > > Cool, 7 bytes of useless padding on 64 bit architectures.
> >
> > All down to the sad inability of certain 64-bit "processor architects"
> > to provide for atomic bit operations on 32-bit integers.
> > If the relatively minor bloat in knfsd worries you, then I advise you
> > to take a deep breath before peeking at struct page... 8-)
>
> You've missed the point. Between sk_inuse and sk_flags is 7 bytes of
> padding. Yes, I'm aware that sk_flags has 7 bytes of unused space, but
> that's the unavoidable part. Personally, I think the sunrpc code should
> do this particular operation differently.
Code is welcome. Even detailed description of "differently" is
welcome.
At the time, I was interested in "cleaner" and "works", both of which
I achieved. "best" takes a bit longer.
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long....
2002-08-20 23:21 ` Benjamin LaHaise
2002-08-20 23:32 ` Neil Brown
@ 2002-08-20 23:44 ` Trond Myklebust
1 sibling, 0 replies; 6+ messages in thread
From: Trond Myklebust @ 2002-08-20 23:44 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: nfs
>>>>> " " == Benjamin LaHaise <bcrl@redhat.com> writes:
> You've missed the point. Between sk_inuse and sk_flags is 7
> bytes of padding. Yes, I'm aware that sk_flags has 7 bytes of
> unused space, but that's the unavoidable part. Personally, I
> think the sunrpc code should do this particular operation
> differently.
Fair enough: I agree that sk_flags could be moved to the top of the
struct. However in practice I doubt you'll see any gain whatsoever,
given that all the struct svc_sock get kmalloc()ed one by one...
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-08-20 23:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-20 4:24 PATCH - SUNRPC 1 of 3 - The new "sk_flags" word in struct svc_sock must be long Neil Brown
2002-08-20 22:53 ` Benjamin LaHaise
2002-08-20 23:16 ` Trond Myklebust
2002-08-20 23:21 ` Benjamin LaHaise
2002-08-20 23:32 ` Neil Brown
2002-08-20 23:44 ` Trond Myklebust
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.