Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
On Feb 20, 2015, at 5:14 PM, Dominik Hassler hassl...@gmx.li wrote:
Dan,
I had a look at HVM-807 you mentioned.
Shouldn't line 251 in 'net/vnic.c' be
for (i = 0; i MIN(iovcnt, FRAMEIO_NVECS_MAX); i++, iov++) {
instead of
for (i = 0; i MIN(iovcnt, FRAMEIO_NVECS_MAX - 1); i++, iov++) {
As otherwise the last element of the frameio will not be used at all if
iovcnt is greater than the frameio buffer size?
I've no idea, honestly. I count on upstream (Joyent) to look at all of that.
If you've found a genuine problem in illumos-kvm or illumos-kvm-cmd, perhaps
pinging smartos-discuss, or some other appropriate list may be your best bet.
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
never mind, it's getting filled later on.
should have had a look at the whole of it before starting to bark :/
sorry for the noise!
On 02/20/2015 11:14 PM, Dominik Hassler wrote:
Dan,
I had a look at HVM-807 you mentioned.
Shouldn't line 251 in 'net/vnic.c' be
for (i = 0; i MIN(iovcnt, FRAMEIO_NVECS_MAX); i++, iov++) {
instead of
for (i = 0; i MIN(iovcnt, FRAMEIO_NVECS_MAX - 1); i++, iov++) {
As otherwise the last element of the frameio will not be used at all if
iovcnt is greater than the frameio buffer size?
Kind regards
Dominik
On 02/20/2015 09:17 PM, Dan McDonald wrote:
On Feb 20, 2015, at 2:58 PM, Tobias Oetiker t...@oetiker.ch wrote:
Hi Dan,
I do not have a spare machine to test this, but if the dramatic
network io performance regression for kvm present in r151012 has
not been fixed in r151014 then we will be stranded on r151010.
And the upstreaming of VND is likely not to happen with this release. That
blocks us from properly catching up with illumos-kvm-cmd.
There are several commits (Starting with the March 19th one we can't bring
in w/o VND) here:
https://github.com/joyent/illumos-kvm-cmd/commits/master
Currently, we only backport the most recent fix about QEMU using
preadv/pwritev recklessly. IF (big if) there are other commits we can
backport, you could try it using the patches/ directory of omnios-build.
I'm thinking maybe HVM-807's may help you (provided that's indepdent of VND
support).
Have you seen anything with dtrace or lockstat that could give a clue to
what's holding things up? I don't recall seeing anything observed.
Judging from the echo on the ML, not many people seem to see this
problem, or care about it.
I'm sorry, but that does appear to be the case.
Next week I disappear for other-customer work, but starting in March, I'm
doing nothing but r151014.
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
Dan,
I had a look at HVM-807 you mentioned.
Shouldn't line 251 in 'net/vnic.c' be
for (i = 0; i MIN(iovcnt, FRAMEIO_NVECS_MAX); i++, iov++) {
instead of
for (i = 0; i MIN(iovcnt, FRAMEIO_NVECS_MAX - 1); i++, iov++) {
As otherwise the last element of the frameio will not be used at all if
iovcnt is greater than the frameio buffer size?
Kind regards
Dominik
On 02/20/2015 09:17 PM, Dan McDonald wrote:
On Feb 20, 2015, at 2:58 PM, Tobias Oetiker t...@oetiker.ch wrote:
Hi Dan,
I do not have a spare machine to test this, but if the dramatic
network io performance regression for kvm present in r151012 has
not been fixed in r151014 then we will be stranded on r151010.
And the upstreaming of VND is likely not to happen with this release. That
blocks us from properly catching up with illumos-kvm-cmd.
There are several commits (Starting with the March 19th one we can't bring in
w/o VND) here:
https://github.com/joyent/illumos-kvm-cmd/commits/master
Currently, we only backport the most recent fix about QEMU using
preadv/pwritev recklessly. IF (big if) there are other commits we can
backport, you could try it using the patches/ directory of omnios-build. I'm
thinking maybe HVM-807's may help you (provided that's indepdent of VND
support).
Have you seen anything with dtrace or lockstat that could give a clue to
what's holding things up? I don't recall seeing anything observed.
Judging from the echo on the ML, not many people seem to see this
problem, or care about it.
I'm sorry, but that does appear to be the case.
Next week I disappear for other-customer work, but starting in March, I'm
doing nothing but r151014.
Dan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
0xF9ECC6A5.asc
Description: application/pgp-keys
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
Unicast... Found this: http://echelog.com/logs/browse/smartos/1408053600 With this to say: rmustacc So, I can give you a copy of the analysis. rmustacc Basically the number of iovecs that we can receive is up to the virtio ring buffer size. rmustacc Which is a lot more than the number of frame io vectors. rmustacc And while this shouldn't generally happen, Windows has been guilt of it for non-jumbo frames. rmustacc Why you would break up a 1500 byte packet into 32 iovectors is beyond me. nahamu and when it does that QEMU crashes on the assert with the old code, correct? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
Sometime during Q2CY2015 (no earlier than April 1st), OmniOS r151014 will be released. At that time, support for r151010 (previous stable) will be discontinued. This is in accordance with the OmniOS release cycle: http://omnios.omniti.com/wiki.php/ReleaseCycle If you can, please upgrade to r151012. We *should* be able to allow a jump from r151010 to r151014, as we must support a jump from r151012 to 014 AND from 006 to 014 (because r151014 will also be the next Long-Term Support release). As I mentioned the last time, beadm(1M) is your friend. Creating backup BEs in case of mistakes is easy. Thank you, Dan McDonald -- OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
You know what would be nice? an omnios.omniti.com/releases web page that has the release name, date and EOL [r151006 : LTS] [birth date] [end-of-life date] [r151010 : stable] [birth date] [end-of-life 2015-04-01] [r151013 : bloody] [birth date] [not supported] [r151014 : LTS] [birth we're expecting] [end-of-life date] We could make that nice an pretty and I think it would be very useful. On Fri, Feb 20, 2015 at 11:16 AM, Dan McDonald dan...@omniti.com wrote: Sometime during Q2CY2015 (no earlier than April 1st), OmniOS r151014 will be released. At that time, support for r151010 (previous stable) will be discontinued. This is in accordance with the OmniOS release cycle: http://omnios.omniti.com/wiki.php/ReleaseCycle If you can, please upgrade to r151012. We *should* be able to allow a jump from r151010 to r151014, as we must support a jump from r151012 to 014 AND from 006 to 014 (because r151014 will also be the next Long-Term Support release). As I mentioned the last time, beadm(1M) is your friend. Creating backup BEs in case of mistakes is easy. Thank you, Dan McDonald -- OmniOS Engineering ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
On Feb 20, 2015, at 2:58 PM, Tobias Oetiker t...@oetiker.ch wrote: Hi Dan, I do not have a spare machine to test this, but if the dramatic network io performance regression for kvm present in r151012 has not been fixed in r151014 then we will be stranded on r151010. And the upstreaming of VND is likely not to happen with this release. That blocks us from properly catching up with illumos-kvm-cmd. There are several commits (Starting with the March 19th one we can't bring in w/o VND) here: https://github.com/joyent/illumos-kvm-cmd/commits/master Currently, we only backport the most recent fix about QEMU using preadv/pwritev recklessly. IF (big if) there are other commits we can backport, you could try it using the patches/ directory of omnios-build. I'm thinking maybe HVM-807's may help you (provided that's indepdent of VND support). Have you seen anything with dtrace or lockstat that could give a clue to what's holding things up? I don't recall seeing anything observed. Judging from the echo on the ML, not many people seem to see this problem, or care about it. I'm sorry, but that does appear to be the case. Next week I disappear for other-customer work, but starting in March, I'm doing nothing but r151014. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010
Hi Dan, Today Dan McDonald wrote: Sometime during Q2CY2015 (no earlier than April 1st), OmniOS r151014 will be released. At that time, support for r151010 (previous stable) will be discontinued. This is in accordance with the OmniOS release cycle: http://omnios.omniti.com/wiki.php/ReleaseCycle If you can, please upgrade to r151012. We *should* be able to allow a jump from r151010 to r151014, as we must support a jump from r151012 to 014 AND from 006 to 014 (because r151014 will also be the next Long-Term Support release). As I mentioned the last time, beadm(1M) is your friend. Creating backup BEs in case of mistakes is easy. I do not have a spare machine to test this, but if the dramatic network io performance regression for kvm present in r151012 has not been fixed in r151014 then we will be stranded on r151010. Judging from the echo on the ML, not many people seem to see this problem, or care about it. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch t...@oetiker.ch +41 62 775 9902 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
