All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van der Linden <Frank.Vanderlinden@Sun.COM>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] pygrub: make it work
Date: Thu, 19 Feb 2009 12:01:16 -0700	[thread overview]
Message-ID: <499DAC7C.4020607@Sun.COM> (raw)
In-Reply-To: <18845.43184.961624.895118@mariner.uk.xensource.com>

Ian Jackson wrote:
> 
> I think it would be better to have something that is the same
> everywhere so I'd encourage you to resubmit without the special
> casing (and I'll help fix it if it goes wrong).

I don't have much time right now to test on Linux, but I'll see if I 
can. Maybe Christoph can too.

> Yes, that's a good explanation of the new code.  What seems to be
> lacking is an explanation of what was wrong with the old code - ie,
> what should go in the changeset comment.
>

The comments do explain what was wrong with the old code..

The old code had the following problems:

1) It was reading and writing data one byte at the time, leading
    to overhead. However, it's safe to try to read/write bigger
    chunks, since the filedescriptors are NDELAY.
2) Instead of checking len(outbuf) / len(inbuf) for writes,
    simply do not include those filedescriptors in the select if there is
    nothing to write. Otherwise, the loop would run around in circles:
    the select would find that the output filedescriptors were writeable,
    but then the loop code would find that it had nothing to write to
    them. In the next iteration, the write filedescs would still be
    writeable, so select returns immediately, but there would still be no
    data to write. Etc, etc. It was essentially a while (1) until
    there was actual data to write. A waste of CPU cycles.

- Frank

  reply	other threads:[~2009-02-19 19:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-19  9:48 [PATCH] pygrub: make it work Christoph Egger
2009-02-19 17:37 ` Ian Jackson
2009-02-19 18:16   ` Frank van der Linden
2009-02-19 18:45     ` Ian Jackson
2009-02-19 19:01       ` Frank van der Linden [this message]
2009-02-23 16:25         ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=499DAC7C.4020607@Sun.COM \
    --to=frank.vanderlinden@sun.com \
    --cc=Christoph.Egger@amd.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.