From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Robert Yang <liezhi.yang@windriver.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH 1/2] V4 Disk space monitoring
Date: Sat, 25 Feb 2012 11:51:24 +0000 [thread overview]
Message-ID: <1330170684.13788.29.camel@ted> (raw)
In-Reply-To: <4F48C122.1030200@windriver.com>
On Sat, 2012-02-25 at 19:08 +0800, Robert Yang wrote:
> Thank you very much for your detailed review, I've fixed most of
> them as you suggested except the following ones, and please see my
> comments below.
Thanks! (comments below)
> On 02/23/2012 01:28 AM, Richard Purdie wrote:
> > Hi Robert,
> >
> >> # Set disk space and inode interval, the unit can be G, M, or K, but do
> >> # NOT use the GB, MB or KB (B is not needed), the format is:
> >> # "disk space interval, disk inode interval", the default value is
> >> # "10M, 50" which means that it would warn when the free space is
> >> # lower than the minimum space(or inode), and would repeat the action
> >> # when the disk space reduces 10M (or the amount of inode reduces 50)
> >> # again.
> >> #BB_DISKMON_INTERVAL = "10M,10K"
> >
> > I'm wondering how useful this interval is? Surely once we've warned,
> > aborted or stopped starting new tasks, running the action again isn't
> > much use? This is particularly true with the change I'm proposing above.
> >
>
> I think there are 3 actions we can do: WARN, STOPTASKS or ABORT, this is
> only useful for "WARN", when the action is "WARN", there would be too many
> WARNINGS without the interval value.
Can we call it BB_DISKMON_WARNINTERVAL then?
> >> + for dev in devDict:
> >> + st = os.statvfs(devDict[dev][0])
> >> + # The free space, float point number
> >> + freeSpace = st.f_bavail * st.f_frsize
> >> + if devDict[dev][1] is not None and freeSpace< devDict[dev][1]:
> >> + # Always show warning, and this is the default "WARN" action
> >> + if self.preFreeSpace[dev] == 0 or self.preFreeSpace[dev] - freeSpace> self.dm.spaceInterval:
> >> + logger.warn("The free space of %s is running low (%.3fGB left)" % (dev, freeSpace / 1024 / 1024 / 1024.0))
> >> + self.preFreeSpace[dev] = freeSpace
> >> + if self.dm.action == "NO_NEW_TASK":
> >> + logger.warn("No new tasks can be excuted since BB_DISKMON_ACTION = \"NO_NEW_TASK\"!")
> >> + return 1
> >> + elif self.dm.action == "ABORT":
> >> + logger.error("Immediately abort since BB_DISKMON_ACTION = \"ABORT\"!")
> >> + sys.exit(1)
> >
> > Please don't do this. There is a way to immediately abort the runqueue
> > by calling rq.finish_runqueue(True) (see cooker.py which does this).
> >
> > The return one could probably also be a finish_runqueue(False) call.
>
> The finish_runqueue(False) works, but finish_runqueue(True) doesn't work
> if there is no running task running(for example, when we use the
> finish_runqueue(True) at the very beginning of the build), this is because
> if there is no running taks, the function would do nothing. So I use:
>
> rq.finish_runqueue(True)
> return False
>
> Then the build would always stop whether there is running tasks or not.
Ah, right. How about we add as a separate patch:
diff --git a/bitbake/lib/bb/runqueue.py b/bitbake/lib/bb/runqueue.py
index c24841f..09dab3d 100644
--- a/bitbake/lib/bb/runqueue.py
+++ b/bitbake/lib/bb/runqueue.py
@@ -1060,6 +1060,13 @@ class RunQueueExecute:
for pipe in self.build_pipes:
self.build_pipes[pipe].read()
+ if len(self.failed_fnids) != 0:
+ self.rq.state = runQueueFailed
+ return
+
+ self.rq.state = runQueueComplete
+ return
+
def finish(self):
self.rq.state = runQueueCleanUp
> This would make the code more clearer, I have moved most of the code to
> lib/bb/monitordisk.py as you suggested, but since the rq.finish_runqueue(True)
> doesn't work when there is no running task, I still need check the return
> status of the monitor, now the code is:
>
> if self.state in [runQueueSceneRun, runQueueRunning, runQueueCleanUp]:
> if self.dm.enableMonitor:
> dm_ret = self.dm.dm_action()
> if dm_ret == 1:
> self.finish_runqueue(False)
> elif dm_ret == 2:
> self.finish_runqueue(True)
> return False
See above, I think we can fix this! :)
Cheers,
Richard
next prev parent reply other threads:[~2012-02-25 11:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 9:53 [PATCH 0/2] V4 Disk space monitoring Robert Yang
2012-02-20 9:53 ` [PATCH 1/2] " Robert Yang
2012-02-22 17:28 ` Richard Purdie
2012-02-25 11:08 ` Robert Yang
2012-02-25 11:51 ` Richard Purdie [this message]
2012-02-20 9:53 ` [PATCH 2/2] V4 Add config sample for disk " Robert Yang
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=1330170684.13788.29.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-devel@lists.openembedded.org \
--cc=liezhi.yang@windriver.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.