Hi,
Please move any further comments on this thread to:
https://reviews.freebsd.org/D1438
See r277528. Discussion ends here.
--HPS
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send
Hans:
We (netflix) run in production 35% of the internet with these very things
you identify no lock an all. We *do* have some issue we are looking at but so
far
I have *never* connected the dots the way you were claiming that would
cause a crash. I can see where TCP would do incorrect
Let me re-send my email.. my silly mac sent my first try from the wrong
address.. sigh
(sorry moderator where ever you are ;-o)
All:
I have finally pulled my head out of the sands of TLS and
had some time to look at this interesting long thread. I agree
with Warner and Adrian on this.. Lets
Hans
Thats great, could you please open a project branch that
we can look at it in too?
I would very much appreciate that. Sometimes I like to look
at the whole code with it all in place (not just patches) and a project
branch really helps with that.
R
On Jan 22, 2015, at 3:39 AM, Hans Petter
Hans:
I think this is the wrong approach.
You should:
a) Back out the commit you did to head
b) create a project branch and put your changes in there
c) fix *everything* you break in these subtle ways
d) Discuss through a review process if your changes are correct
e) When consensus is reached
On 01/22/15 12:26, Randy Stewart wrote:
Hans:
We (netflix) run in production 35% of the internet with these very things
you identify no lock an all. We *do* have some issue we are looking at but so
far
I have *never* connected the dots the way you were claiming that would
cause a crash. I can
All:
I have finally pulled my head out of the sands of TLS and
had some time to look at this interesting long thread. I agree
with Warner and Adrian on this.. Lets back it out
and then in a branch chew this over piece by piece..
R
On Jan 21, 2015, at 7:10 PM, Adrian Chadd adr...@freebsd.org
On Thu, Jan 22, 2015 at 08:14:26AM +0100, Hans Petter Selasky wrote:
On 01/22/15 06:26, Warner Losh wrote:
The code simply needs an update. It is not broken in any ways - right? If
it is not broken, fixing it is not that urgent.
Radically changing the performance characteristics is
On 01/22/15 09:10, Konstantin Belousov wrote:
On Thu, Jan 22, 2015 at 08:14:26AM +0100, Hans Petter Selasky wrote:
On 01/22/15 06:26, Warner Losh wrote:
The code simply needs an update. It is not broken in any ways - right? If it is
not broken, fixing it is not that urgent.
Radically
On 01/22/15 10:49, K. Macy wrote:
Sigh, you still do not understand. It is your duty to identify all pieces
which break after your change. After that, we can argue whether each of
them is critical or not to allow the migration. But this must have been
done before the KPI change hit the tree.
http://www.mrs-realestate.blogspot.in/
2400sq.ft 2400*200=48 only near (sez-3) tamilnadu
6km only sez-3
after 10 year land valu w
contact:7373730713(sms only)
___
svn-src-head@freebsd.org mailing list
Sigh, you still do not understand. It is your duty to identify all pieces
which break after your change. After that, we can argue whether each of
them is critical or not to allow the migration. But this must have been
done before the KPI change hit the tree.
Hi,
Are you saying that
Sean,
On Tue, Jan 20, 2015 at 04:22:44PM -0800, Sean Bruno wrote:
S In our universe, this commit (right or wrong) resolved our panics. I
S think that there is some room for improvement based on the commentary
S in this thread, but some people do indeed prefer stability over
S performance. I
On 21 January 2015 at 10:15, Gleb Smirnoff gleb...@freebsd.org wrote:
Sean,
On Tue, Jan 20, 2015 at 04:22:44PM -0800, Sean Bruno wrote:
S In our universe, this commit (right or wrong) resolved our panics. I
S think that there is some room for improvement based on the commentary
S in this
On 21 January 2015 at 06:00, Lawrence Stewart lstew...@freebsd.org wrote:
On 01/20/15 09:22, Adrian Chadd wrote:
Yeah, it looks like you set c_cpu to timeout_cpu in
_callout_init_locked(), but then you only handle the case of the CPU
being changed in certain circumstances. You aren't handling
HPS: Your change failed to meet these guidelines. Some of us are upset
because these guidelines are fairly fundamental for the on-going
viability of FreeBSD. Due to linguistic / time zone / cultural
differences these expectations have not been adequately communicated
to you. You are not in
On 21 January 2015 at 16:07, K. Macy km...@freebsd.org wrote:
HPS: Your change failed to meet these guidelines. Some of us are upset
because these guidelines are fairly fundamental for the on-going
viability of FreeBSD. Due to linguistic / time zone / cultural
differences these expectations
They originally found that things were spinning for way too long.
Hans found something similar and determined/concluded that the
migration code in callouts was racy-by-design and dramatically
simplified it and also put very hard constraints on what is a valid
situation to support migrating
On Jan 21, 2015, at 4:38 PM, K. Macy km...@freebsd.org wrote:
They originally found that things were spinning for way too long.
Hans found something similar and determined/concluded that the
migration code in callouts was racy-by-design and dramatically
simplified it and also put very
On Jan 20, 2015, at 12:51 AM, Konstantin Belousov kostik...@gmail.com wrote:
Do other people consider this situation acceptable ?
Not even a little.
Warner
___
svn-src-head@freebsd.org mailing list
On Jan 20, 2015, at 12:35 AM, Hans Petter Selasky h...@selasky.org wrote:
On 01/20/15 06:22, Adrian Chadd wrote:
Sweet, thanks. I'l test it, but anything that changes the locking to
TCP is going to need a more thorough review. The there be dragons
disclaimer is appropriate.:)
No changes
On Jan 20, 2015, at 2:37 AM, Hans Petter Selasky h...@selasky.org wrote:
On 01/20/15 10:00, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote:
On 01/20/15 08:51, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter
On 01/22/15 06:26, Warner Losh wrote:
The code simply needs an update. It is not broken in any ways - right? If it is
not broken, fixing it is not that urgent.
Radically changing the performance characteristics is breaking the code.
Performance regression in the TCP stack is urgent to fix.
On 01/21/15 01:49, Adrian Chadd wrote:
You should totally try say, 100,000 active TCP connections on a box.
See what happens to swi0 (clock).
TL;DR - the lock contention sucks and it takes a chunk of the core up.
The lock contention is highly not good.
That's why I'd like to see both the
On Wed, Jan 21, 2015 at 09:32:11AM +0100, Hans Petter Selasky wrote:
On 01/21/15 00:53, Sean Bruno wrote:
Unkown to me. Nor am I aware of anyone else who ever hit our panics
either. Our environment, and the failure, was only seen in the Intel
10GE space (ixgbe). This is an artifact of
On 01/21/15 09:51, Konstantin Belousov wrote:
On Wed, Jan 21, 2015 at 09:32:11AM +0100, Hans Petter Selasky wrote:
On 01/21/15 00:53, Sean Bruno wrote:
Unkown to me. Nor am I aware of anyone else who ever hit our panics
either. Our environment, and the failure, was only seen in the Intel
On Tue, Jan 20, 2015 at 04:37:44PM -0800, K. Macy wrote:
I would pick stability over performance any day. However, it _seems_
to me, and maybe I simply don't understand some key details, that the
fix consisted of largely single-threading the callout system. And as I
say I may simply not
On 01/21/15 00:53, Sean Bruno wrote:
Unkown to me. Nor am I aware of anyone else who ever hit our panics
either. Our environment, and the failure, was only seen in the Intel
10GE space (ixgbe). This is an artifact of our use cases, and hasn't
been expanded nor tested in our environment with
On 01/20/15 09:22, Adrian Chadd wrote:
Yeah, it looks like you set c_cpu to timeout_cpu in
_callout_init_locked(), but then you only handle the case of the CPU
being changed in certain circumstances. You aren't handling the CPU
being initialised when the callout is first added.
And,
On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote:
On 01/20/15 08:51, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky wrote:
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please check what the results of this are with CPU
On 01/20/15 10:00, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote:
On 01/20/15 08:51, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky wrote:
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please
On 20 January 2015 at 04:37, Hans Petter Selasky h...@selasky.org wrote:
It is not very hard to update existing callout clients and you can do it
too, if you need the extra bits of performance.
Hi Hans Petter,
The issue here is that the onus is on the one changing a KPI to
support its
On 15 January 2015 at 13:53, John Baldwin j...@freebsd.org wrote:
I think it's been a
clear practice with all other changes reviewed in phabric to date that
the committer only lists people in 'Reviewed by' who actually signed off
on the patch, not just the list of people asked to review it.
On Tue, Jan 20, 2015 at 10:37:52AM +0100, Hans Petter Selasky wrote:
On 01/20/15 10:00, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote:
On 01/20/15 08:51, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky
On 20 January 2015 at 06:25, Ed Maste ema...@freebsd.org wrote:
On 20 January 2015 at 04:37, Hans Petter Selasky h...@selasky.org wrote:
It is not very hard to update existing callout clients and you can do it
too, if you need the extra bits of performance.
Hi Hans Petter,
The issue here
On Tuesday, January 20, 2015 4:37:52 am Hans Petter Selasky wrote:
On 01/20/15 10:00, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote:
On 01/20/15 08:51, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:40, K. Macy wrote:
I think you're working around driver locking bugs by crippling the
callout code.
-K
We had zero evidence of this. What leads you down that path? I'm
totally open to being wrong, e.g. yeah, you slowed down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:39, Navdeep Parhar wrote:
Sean,
Was this really Reviewed by: sbruno@ or just Tested by:
sbruno@? I was very happy to see so many reviewers on the
original commit but you seem to be the only one still left on the
list.
On 20 January 2015 at 14:30, Hans Petter Selasky h...@selasky.org wrote:
Backing out my callout API patch means we will for sure re-introduce an
unknown callout spinlock hang, as noted to me by several people. What do you
think about that?
Maybe Jason Wolfe CC'ed can add to 10-stable w/o my
Please back this out now. It was a substantial interface change
without review. This should not be up for debate. I hope the others
have the fortitude to insist upon this.
-K
On Thu, Jan 15, 2015 at 7:32 AM, Hans Petter Selasky
hsela...@freebsd.org wrote:
Author: hselasky
Date: Thu Jan 15
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:48, K. Macy wrote:
Are any other drivers hitting this? e.g. cxgb/cxgbe?
-K
Unkown to me. Nor am I aware of anyone else who ever hit our panics
either. Our environment, and the failure, was only seen in the Intel
10GE space
On Tue, Jan 20, 2015 at 3:48 PM, K. Macy km...@freebsd.org wrote:
Are any other drivers hitting this? e.g. cxgb/cxgbe?
The evidence is simply past experience of recurring locking and
control flow bugs in the intel drivers.
-K
-K
On Tue, Jan 20, 2015 at 3:46 PM, Sean Bruno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:59, K. Macy wrote:
On Tue, Jan 20, 2015 at 3:53 PM, Sean Bruno
sbr...@ignoranthack.me wrote: On 01/20/15 15:48, K. Macy wrote:
Are any other drivers hitting this? e.g. cxgb/cxgbe?
-K
Unkown to me. Nor am I aware of anyone
On Tue, Jan 20, 2015 at 4:22 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:59, K. Macy wrote:
On Tue, Jan 20, 2015 at 3:53 PM, Sean Bruno
sbr...@ignoranthack.me wrote: On 01/20/15 15:48, K. Macy wrote:
Are any other drivers
On Tue, Jan 20, 2015 at 09:51:26AM +0200, Konstantin Belousov wrote:
K Like stated in the manual page, callout_reset_curcpu/on() does not work
K with MPSAFE callouts any more!
K I.e. you 'fixed' some undeterminate bugs in callout migration by not
K doing migration at all anymore.
K
K
K You
I think you're working around driver locking bugs by crippling the callout code.
-K
On Tue, Jan 20, 2015 at 3:35 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 14:30, Hans Petter Selasky wrote:
On 01/20/15 22:11, Gleb Smirnoff wrote:
On Tue, Jan 20, 2015 at 3:53 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:48, K. Macy wrote:
Are any other drivers hitting this? e.g. cxgb/cxgbe?
-K
Unkown to me. Nor am I aware of anyone else who ever hit our panics
Hans,
On Tue, Jan 20, 2015 at 10:37:52AM +0100, Hans Petter Selasky wrote:
H It is not very hard to update existing callout clients and you can do it
H too, if you need the extra bits of performance.
If it is not very hard, then you should have done that as part of
your change.
H Are there
On 01/20/15 22:11, Gleb Smirnoff wrote:
On Tue, Jan 20, 2015 at 09:51:26AM +0200, Konstantin Belousov wrote:
K Like stated in the manual page, callout_reset_curcpu/on() does not work
K with MPSAFE callouts any more!
K I.e. you 'fixed' some undeterminate bugs in callout migration by not
K doing
Sean,
Was this really Reviewed by: sbruno@ or just Tested by: sbruno@? I
was very happy to see so many reviewers on the original commit but you
seem to be the only one still left on the list.
Regards,
Navdeep
On 01/20/15 15:35, Sean Bruno wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 14:30, Hans Petter Selasky wrote:
On 01/20/15 22:11, Gleb Smirnoff wrote:
On Tue, Jan 20, 2015 at 09:51:26AM +0200, Konstantin Belousov
wrote: K Like stated in the manual page,
callout_reset_curcpu/on() does not work K with MPSAFE
Are any other drivers hitting this? e.g. cxgb/cxgbe?
-K
On Tue, Jan 20, 2015 at 3:46 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:40, K. Macy wrote:
I think you're working around driver locking bugs by crippling the
callout
On 19 January 2015 at 20:30, Hans Petter Selasky h...@selasky.org wrote:
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please check what the results of this are with CPU specific
callwheels?
I'm doing some 10+ gig traffic testing on -HEAD with RSS enabled (on
ixgbe) and with this
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please check what the results of this are with CPU specific
callwheels?
I'm doing some 10+ gig traffic testing on -HEAD with RSS enabled (on
ixgbe) and with this setup, the per-CPU TCP callwheel stuff is
enabled. But all the callwheels are
On 01/19/15 23:22, Adrian Chadd wrote:
In my instance, I'm seeing quite a lot of lock contention between the
userland threads, the network RX threads and the clock thread, all
contending on a single callout wheel being used for TCP timers. One of
the early goals for fixing up the RSS stuff in
On 01/20/15 06:22, Adrian Chadd wrote:
Sweet, thanks. I'l test it, but anything that changes the locking to
TCP is going to need a more thorough review. The there be dragons
disclaimer is appropriate.:)
No changes in locking - simply some minor code reordering.
--HPS
On 01/20/15 08:51, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky wrote:
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please check what the results of this are with CPU specific
callwheels?
I'm doing some 10+ gig traffic testing on -HEAD with
Hi,
Have a look here:
https://reviews.freebsd.org/D1563
Give me a hand and test and review this patch properly!
--HPS
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky wrote:
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please check what the results of this are with CPU specific
callwheels?
I'm doing some 10+ gig traffic testing on -HEAD with RSS enabled (on
ixgbe) and with this
On 01/20/15 06:04, Adrian Chadd wrote:
On 19 January 2015 at 20:30, Hans Petter Selasky h...@selasky.org wrote:
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please check what the results of this are with CPU specific
callwheels?
I'm doing some 10+ gig traffic testing on -HEAD with
On 19 January 2015 at 21:20, Hans Petter Selasky h...@selasky.org wrote:
On 01/20/15 06:04, Adrian Chadd wrote:
On 19 January 2015 at 20:30, Hans Petter Selasky h...@selasky.org wrote:
On 01/19/15 22:59, Adrian Chadd wrote:
Hi,
Would you please check what the results of this are with CPU
Hi,
Would you please check what the results of this are with CPU specific
callwheels?
I'm doing some 10+ gig traffic testing on -HEAD with RSS enabled (on
ixgbe) and with this setup, the per-CPU TCP callwheel stuff is
enabled. But all the callwheels are now back on clock(0) and so is the
lock
Yeah, it looks like you set c_cpu to timeout_cpu in
_callout_init_locked(), but then you only handle the case of the CPU
being changed in certain circumstances. You aren't handling the CPU
being initialised when the callout is first added.
And, callout_restart_async() calls callout_lock(), which
On 15 Jan 2015, at 15:32 , Hans Petter Selasky hsela...@freebsd.org wrote:
Author: hselasky
Date: Thu Jan 15 15:32:30 2015
New Revision: 277213
URL: https://svnweb.freebsd.org/changeset/base/277213
Log:
Major callout subsystem cleanup and rewrite:
I see this for i386 and amd64 LINT*
On Thu, Jan 15, 2015 at 05:05:58PM +0100, Hans Petter Selasky wrote:
The Reviewed by was simply a CP of the review list in from the
Differential Revision. When you mention it should probably simply have said:
Reviewed by: sbruno @
Due to the meaning of Reviewed by in commit messages.
On Thu, Jan 15, 2015 at 08:14:30PM +0300, Gleb Smirnoff wrote:
T I'd dare to say that such important change simply cannot be committed
T with a thorough review from at least two people very confident in this
T area.
Of course, I typoed. I meant cannot be committed withOUT a thorough review.
--
On Thu, Jan 15, 2015 at 7:32 AM, Hans Petter Selasky
hsela...@freebsd.org wrote:
Author: hselasky
Date: Thu Jan 15 15:32:30 2015
New Revision: 277213
URL: https://svnweb.freebsd.org/changeset/base/277213
Log:
Major callout subsystem cleanup and rewrite:
I plan to review this as well --
On 1/15/15 12:15 PM, Gleb Smirnoff wrote:
On Thu, Jan 15, 2015 at 08:14:30PM +0300, Gleb Smirnoff wrote:
T I'd dare to say that such important change simply cannot be committed
T with a thorough review from at least two people very confident in this
T area.
Of course, I typoed. I meant
Hans,
On Thu, Jan 15, 2015 at 05:05:58PM +0100, Hans Petter Selasky wrote:
H Eh, I have not reviewed this at all. (I still plan to though.)
H
H The Reviewed by was simply a CP of the review list in from the
H Differential Revision. When you mention it should probably simply have said:
H
H
Author: hselasky
Date: Thu Jan 15 15:32:30 2015
New Revision: 277213
URL: https://svnweb.freebsd.org/changeset/base/277213
Log:
Major callout subsystem cleanup and rewrite:
- Close a migration race where callout_reset() failed to set the
CALLOUT_ACTIVE flag.
- Callout callback functions
On 15 January 2015 at 10:53, John Baldwin j...@freebsd.org wrote:
On 1/15/15 10:32 AM, Hans Petter Selasky wrote:
Author: hselasky
Date: Thu Jan 15 15:32:30 2015
New Revision: 277213
URL: https://svnweb.freebsd.org/changeset/base/277213
Eh, I have not reviewed this at all. (I still plan to
On 01/15/15 16:53, John Baldwin wrote:
On 1/15/15 10:32 AM, Hans Petter Selasky wrote:
Author: hselasky
Date: Thu Jan 15 15:32:30 2015
New Revision: 277213
URL: https://svnweb.freebsd.org/changeset/base/277213
Hi,
Eh, I have not reviewed this at all. (I still plan to though.)
The
On 1/15/15 10:32 AM, Hans Petter Selasky wrote:
Author: hselasky
Date: Thu Jan 15 15:32:30 2015
New Revision: 277213
URL: https://svnweb.freebsd.org/changeset/base/277213
Log:
Major callout subsystem cleanup and rewrite:
- Close a migration race where callout_reset() failed to set the
On 01/15/15 19:46, Bjoern A. Zeeb wrote:
On 15 Jan 2015, at 15:32 , Hans Petter Selasky hsela...@freebsd.org wrote:
Author: hselasky
Date: Thu Jan 15 15:32:30 2015
New Revision: 277213
URL: https://svnweb.freebsd.org/changeset/base/277213
Log:
Major callout subsystem cleanup and rewrite:
74 matches
Mail list logo
