Re: setting tunables in stable/10 vs head?

2015-06-11 Thread Hans Petter Selasky

On 06/11/15 06:23, hiren panchasara wrote:

On 06/10/15 at 10:07P, Ian Lepore wrote:

On Wed, 2015-06-10 at 20:44 -0700, hiren panchasara wrote:

On 06/10/15 at 04:13P, Rick Macklem wrote:

Hi,

I just MFC'd a patch from head to stable/10 that defines some
tunables using CTLFLAG_RDTUN. Although the MFC didn't break
anything, the tunables don't get changed by the values in /boot/loader.conf.

By applying a patch like this:
  SYSCTL_DECL(_vfs_nfsd);
  int   nfsrv_statehashsize = NFSSTATEHASHSIZE;
+TUNABLE_INT(vfs.nfsd.statehashsize, nfsrv_statehashsize);
  SYSCTL_INT(_vfs_nfsd, OID_AUTO, statehashsize, CTLFLAG_RDTUN,
  nfsrv_statehashsize, 0,
  Size of state hash table set via loader.conf);

they get set ok.

So, is this correct or have I done something stupid?


I believe that is correct. hans changed how they are declared with r267961
and now you do not need TUNABLE_INT() on -head.


And, if it correct, do I commit a patch like the above directly
to stable/10. (It seems that TUNABLE_INT() is discouraged for -head.)


That's the correct way, afaik.

Cheers,
Hiren


Is there a reason the sysctl tunable flag changes can't be MFC'd?
Leaving changes that widespread un-mfc'd just makes for lots of merge
conflicts as time goes on (and can also lead to merged code behaving
differently than expected).


Added Hans to answer the question.


Hi,

I wasn't sure if MFC'ing would break anything with regard to binary 
compatibility, so the change was kept in -head and only the broken 
SYSCTLs were fixed in 10- and 9- .


--HPS

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: setting tunables in stable/10 vs head?

2015-06-11 Thread Hans Petter Selasky

On 06/10/15 22:13, Rick Macklem wrote:

So, is this correct or have I done something stupid?


Yes, this is correct.

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: setting tunables in stable/10 vs head?

2015-06-10 Thread hiren panchasara
On 06/10/15 at 04:13P, Rick Macklem wrote:
 Hi,
 
 I just MFC'd a patch from head to stable/10 that defines some
 tunables using CTLFLAG_RDTUN. Although the MFC didn't break
 anything, the tunables don't get changed by the values in /boot/loader.conf.
 
 By applying a patch like this:
  SYSCTL_DECL(_vfs_nfsd);
  int  nfsrv_statehashsize = NFSSTATEHASHSIZE;
 +TUNABLE_INT(vfs.nfsd.statehashsize, nfsrv_statehashsize);
  SYSCTL_INT(_vfs_nfsd, OID_AUTO, statehashsize, CTLFLAG_RDTUN,
  nfsrv_statehashsize, 0,
  Size of state hash table set via loader.conf);
 
 they get set ok.
 
 So, is this correct or have I done something stupid?

I believe that is correct. hans changed how they are declared with r267961
and now you do not need TUNABLE_INT() on -head.
 
 And, if it correct, do I commit a patch like the above directly
 to stable/10. (It seems that TUNABLE_INT() is discouraged for -head.)

That's the correct way, afaik.

Cheers,
Hiren


pgp2I3ZTCmLLR.pgp
Description: PGP signature


Re: setting tunables in stable/10 vs head?

2015-06-10 Thread Ian Lepore
On Wed, 2015-06-10 at 20:44 -0700, hiren panchasara wrote:
 On 06/10/15 at 04:13P, Rick Macklem wrote:
  Hi,
  
  I just MFC'd a patch from head to stable/10 that defines some
  tunables using CTLFLAG_RDTUN. Although the MFC didn't break
  anything, the tunables don't get changed by the values in /boot/loader.conf.
  
  By applying a patch like this:
   SYSCTL_DECL(_vfs_nfsd);
   intnfsrv_statehashsize = NFSSTATEHASHSIZE;
  +TUNABLE_INT(vfs.nfsd.statehashsize, nfsrv_statehashsize);
   SYSCTL_INT(_vfs_nfsd, OID_AUTO, statehashsize, CTLFLAG_RDTUN,
   nfsrv_statehashsize, 0,
   Size of state hash table set via loader.conf);
  
  they get set ok.
  
  So, is this correct or have I done something stupid?
 
 I believe that is correct. hans changed how they are declared with r267961
 and now you do not need TUNABLE_INT() on -head.
  
  And, if it correct, do I commit a patch like the above directly
  to stable/10. (It seems that TUNABLE_INT() is discouraged for -head.)
 
 That's the correct way, afaik.
 
 Cheers,
 Hiren

Is there a reason the sysctl tunable flag changes can't be MFC'd?
Leaving changes that widespread un-mfc'd just makes for lots of merge
conflicts as time goes on (and can also lead to merged code behaving
differently than expected).

-- Ian

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: setting tunables in stable/10 vs head?

2015-06-10 Thread hiren panchasara
On 06/10/15 at 10:07P, Ian Lepore wrote:
 On Wed, 2015-06-10 at 20:44 -0700, hiren panchasara wrote:
  On 06/10/15 at 04:13P, Rick Macklem wrote:
   Hi,
   
   I just MFC'd a patch from head to stable/10 that defines some
   tunables using CTLFLAG_RDTUN. Although the MFC didn't break
   anything, the tunables don't get changed by the values in 
   /boot/loader.conf.
   
   By applying a patch like this:
SYSCTL_DECL(_vfs_nfsd);
int  nfsrv_statehashsize = NFSSTATEHASHSIZE;
   +TUNABLE_INT(vfs.nfsd.statehashsize, nfsrv_statehashsize);
SYSCTL_INT(_vfs_nfsd, OID_AUTO, statehashsize, CTLFLAG_RDTUN,
nfsrv_statehashsize, 0,
Size of state hash table set via loader.conf);
   
   they get set ok.
   
   So, is this correct or have I done something stupid?
  
  I believe that is correct. hans changed how they are declared with r267961
  and now you do not need TUNABLE_INT() on -head.
   
   And, if it correct, do I commit a patch like the above directly
   to stable/10. (It seems that TUNABLE_INT() is discouraged for -head.)
  
  That's the correct way, afaik.
  
  Cheers,
  Hiren
 
 Is there a reason the sysctl tunable flag changes can't be MFC'd?
 Leaving changes that widespread un-mfc'd just makes for lots of merge
 conflicts as time goes on (and can also lead to merged code behaving
 differently than expected).

Added Hans to answer the question.

Cheers,
Hiren


pgprti_fwNyHA.pgp
Description: PGP signature