qemu-old .. relevent or not?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

qemu-old .. relevent or not?

Todd T. Fries-2
I've gotten one request to decommission qemu-old.  It surprised me,
as I thought there were still issues with qemu/ even with the semi recent
thread fix as well as performance differences.

Does anybody have objection to retiring qemu-old to the attic or ?

I'd rather not do this prematurely but if the time has come, this is the
right time of release cycle to do it.

Thanks,
--
Todd Fries .. [hidden email]

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| 2525 NW Expy #525, Oklahoma City, OK 73112  \  sip:[hidden email]
| "..in support of free software solutions."  \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: qemu-old .. relevent or not?

Henning Brauer-5
* Todd T. Fries <[hidden email]> [2011-03-21 22:01]:
> Does anybody have objection to retiring qemu-old to the attic or ?

yes, I object for the time being.

the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a
chance to try the recently updated 0.14 yet and due to this situation
it'll be a bit, but the previous 0.13.something was oh so much worse
than 0.9.x.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply | Threaded
Open this post in threaded view
|

Re: qemu-old .. relevent or not?

Todd T. Fries-2
In reply to this post by Todd T. Fries-2
I withdraw any thoughts of removing qemu-old anytime soon based on feedback.

Henning confirms performance gains for keeping it.

And we have a reminder that while kqemu is not recommended, it is only usable
on qemu-old.

Penned by Todd T. Fries on 20110321 15:58.35, we have:
| I've gotten one request to decommission qemu-old.  It surprised me,
| as I thought there were still issues with qemu/ even with the semi recent
| thread fix as well as performance differences.
|
| Does anybody have objection to retiring qemu-old to the attic or ?
|
| I'd rather not do this prematurely but if the time has come, this is the
| right time of release cycle to do it.
|
| Thanks,
| --
| Todd Fries .. [hidden email]
|
|  _____________________________________________
| |                                             \  1.636.410.0632 (voice)
| | Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| | http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| | 2525 NW Expy #525, Oklahoma City, OK 73112  \  sip:[hidden email]
| | "..in support of free software solutions."  \  sip:[hidden email]
|  \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
|                                                  
|               37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
|                         http://todd.fries.net/pgp.txt

--
Todd Fries .. [hidden email]

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| 2525 NW Expy #525, Oklahoma City, OK 73112  \  sip:[hidden email]
| "..in support of free software solutions."  \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: qemu-old .. relevent or not?

stanleylieber
In reply to this post by Todd T. Fries-2
> I've gotten one request to decommission qemu-old.  It surprised me,
> as I thought there were still issues with qemu/ even with the semi recent
> thread fix as well as performance differences.
>
> Does anybody have objection to retiring qemu-old to the attic or ?
>
> I'd rather not do this prematurely but if the time has come, this is the
> right time of release cycle to do it.

I'm probably less educated about the functionality of newer qemu than I
should be, but I still use the old version from ports (along with kqemu) to host
Plan 9 on various systems. My understanding is that moving to the newer
version(s) of qemu would introduce a performance hit, since kqemu is deprecated
and whatever newer, fancier kernel integration has been introduced is not yet
supported on OpenBSD.

Is this wildly off-base?

-sl

Reply | Threaded
Open this post in threaded view
|

Re: qemu-old .. relevent or not?

Brad Smith-14
In reply to this post by Henning Brauer-5
On 21/03/11 5:59 PM, Henning Brauer wrote:
> * Todd T. Fries<[hidden email]>  [2011-03-21 22:01]:
>> Does anybody have objection to retiring qemu-old to the attic or ?
>
> yes, I object for the time being.
>
> the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a
> chance to try the recently updated 0.14 yet and due to this situation
> it'll be a bit, but the previous 0.13.something was oh so much worse
> than 0.9.x.

Ok, well when you get your laptops back provide real bug report(s). For
all I know "oh so much worse" was due to the libpthread bug which was
causing the crashing of QEMU and/or hosted OS's within QEMU.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Re: qemu-old .. relevent or not?

Brad Smith-14
In reply to this post by stanleylieber
On 22/03/11 4:54 PM, Stanley Lieber wrote:

>> I've gotten one request to decommission qemu-old.  It surprised me,
>> as I thought there were still issues with qemu/ even with the semi recent
>> thread fix as well as performance differences.
>>
>> Does anybody have objection to retiring qemu-old to the attic or ?
>>
>> I'd rather not do this prematurely but if the time has come, this is the
>> right time of release cycle to do it.
>
> I'm probably less educated about the functionality of newer qemu than I
> should be, but I still use the old version from ports (along with kqemu) to host
> Plan 9 on various systems. My understanding is that moving to the newer
> version(s) of qemu would introduce a performance hit, since kqemu is deprecated
> and whatever newer, fancier kernel integration has been introduced is not yet
> supported on OpenBSD.
>
> Is this wildly off-base?

KQEMU is an unsupported piece of code that no one has ever maintained,
doesn't work on MP kernels and has issues even on SP kernels. It's not
deprecated. It is plain dead, period. No one cared to actually fix it
when the QEMU developers asked on their list for the OS's that actually
used it (*BSD, Solaris) and later some of its design limitations
prevented further progress so support was removed all together.

Taking that out of the picture and doing an apples to apples comparison
can you find any real issues between the versions of QEMU that have a
real effect on your Plan 9 images?

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Re: qemu-old .. relevent or not?

stanleylieber
On Mon, Mar 21, 2011 at 5:53 PM, Brad <[hidden email]> wrote:

> On 22/03/11 4:54 PM, Stanley Lieber wrote:
>>>
>>> I've gotten one request to decommission qemu-old.  It surprised me,
>>> as I thought there were still issues with qemu/ even with the semi recent
>>> thread fix as well as performance differences.
>>>
>>> Does anybody have objection to retiring qemu-old to the attic or ?
>>>
>>> I'd rather not do this prematurely but if the time has come, this is the
>>> right time of release cycle to do it.
>>
>> I'm probably less educated about the functionality of newer qemu than I
>> should be, but I still use the old version from ports (along with kqemu)
>> to host
>> Plan 9 on various systems. My understanding is that moving to the newer
>> version(s) of qemu would introduce a performance hit, since kqemu is
>> deprecated
>> and whatever newer, fancier kernel integration has been introduced is not
>> yet
>> supported on OpenBSD.
>>
>> Is this wildly off-base?
>
> KQEMU is an unsupported piece of code that no one has ever maintained,
> doesn't work on MP kernels and has issues even on SP kernels. It's not
> deprecated. It is plain dead, period. No one cared to actually fix it when
> the QEMU developers asked on their list for the OS's that actually
> used it (*BSD, Solaris) and later some of its design limitations prevented
> further progress so support was removed all together.
>
> Taking that out of the picture and doing an apples to apples comparison can
> you find any real issues between the versions of QEMU that have a real
> effect on your Plan 9 images?

No experimental evidence, yet, but I'm willing to give it a shot. Subjectively,
the old qemu feels quite a bit slower without kqemu.

I'll do some testing.

-sl

Reply | Threaded
Open this post in threaded view
|

Re: qemu-old .. relevent or not?

Brad Smith-14
On 21/03/11 7:08 PM, Stanley Lieber wrote:

> On Mon, Mar 21, 2011 at 5:53 PM, Brad<[hidden email]>  wrote:
>> On 22/03/11 4:54 PM, Stanley Lieber wrote:
>>>>
>>>> I've gotten one request to decommission qemu-old.  It surprised me,
>>>> as I thought there were still issues with qemu/ even with the semi recent
>>>> thread fix as well as performance differences.
>>>>
>>>> Does anybody have objection to retiring qemu-old to the attic or ?
>>>>
>>>> I'd rather not do this prematurely but if the time has come, this is the
>>>> right time of release cycle to do it.
>>>
>>> I'm probably less educated about the functionality of newer qemu than I
>>> should be, but I still use the old version from ports (along with kqemu)
>>> to host
>>> Plan 9 on various systems. My understanding is that moving to the newer
>>> version(s) of qemu would introduce a performance hit, since kqemu is
>>> deprecated
>>> and whatever newer, fancier kernel integration has been introduced is not
>>> yet
>>> supported on OpenBSD.
>>>
>>> Is this wildly off-base?
>>
>> KQEMU is an unsupported piece of code that no one has ever maintained,
>> doesn't work on MP kernels and has issues even on SP kernels. It's not
>> deprecated. It is plain dead, period. No one cared to actually fix it when
>> the QEMU developers asked on their list for the OS's that actually
>> used it (*BSD, Solaris) and later some of its design limitations prevented
>> further progress so support was removed all together.
>>
>> Taking that out of the picture and doing an apples to apples comparison can
>> you find any real issues between the versions of QEMU that have a real
>> effect on your Plan 9 images?
>
> No experimental evidence, yet, but I'm willing to give it a shot. Subjectively,
> the old qemu feels quite a bit slower without kqemu.

Of course. That's an apples to oranges comparison.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.