Expensive fuser in progress_bar.sh

El Lunes, 26 de Junio de 2006 15:35, Dan Nicholson escribió:

> Attached is one solution that is working on my box (so
far).  The
> whole system is noticeably less sluggish while
building.  `top' looks
> normal again.

That have a big bug: if the build of some target fails (or
you press 
Control-C), progress-bar.sh will loop for ever in the
background.

I will see if we can do the exit tests each second instead
of each 120 
milliseconds, But that could need a "sleep 1.2"
instead current "sleep .25"

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 6/28/06, M.Canales.es <manuellinuxfromscratch.org>
wrote:
> El Lunes, 26 de Junio de 2006 15:35, Dan Nicholson
escribió:
>
> > Attached is one solution that is working on my box
(so far).  The
> > whole system is noticeably less sluggish while
building.  `top' looks
> > normal again.
>
> That have a big bug: if the build of some target fails
(or you press
> Control-C), progress-bar.sh will loop for ever in the
background.

That's why I added "rm -f /tmp/jhalfs.*" to the
traps in master.sh.
Would that not work?

> I will see if we can do the exit tests each second
instead of each 120
> milliseconds, But that could need a "sleep
1.2" instead current "sleep .25"

It just has to be a different test than running fuser.  It
considerably slowed down my build.  With jhalfs, 1 SBU =
19m.  Without
jhalfs, 1 SBU = 10m.  gcc took forever.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

M.Canales.es wrote:
> El Lunes, 26 de Junio de 2006 15:35, Dan Nicholson
escribió:
> 
>> Attached is one solution that is working on my box
(so far).  The
>> whole system is noticeably less sluggish while
building.  `top' looks
>> normal again.
> 
> That have a big bug: if the build of some target fails
(or you press 
> Control-C), progress-bar.sh will loop for ever in the
background.

  I found this tidbit of info but have not played with it
yet. To 
implement this method would require some recoding and
testing. It this 
works maybe we could add it to the experimental release.

http://www.linuxforums.org/forum/linux-programming-scrip
ting/20405-error-handling-gnu-make-sic-yes-its-possible.html


> 
> I will see if we can do the exit tests each second
instead of each 120 
> milliseconds, But that could need a "sleep
1.2" instead current "sleep .25"
> 
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Miércoles, 28 de Junio de 2006 19:51, Dan Nicholson
escribió:

> That's why I added "rm -f /tmp/jhalfs.*"
to the traps in master.sh.
> Would that not work?

The code in master.sh is used only to generate the build
scripts and Makefile, 
not when running the Makefile.

> It just has to be a different test than running fuser. 
It
> considerably slowed down my build.  With jhalfs, 1 SBU
= 19m.  Without
> jhalfs, 1 SBU = 10m.  gcc took forever.

Ufff.. In my system there is only some seconds of
difference.

We need a less intrussive way to test that make is alive.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Miércoles, 28 de Junio de 2006 19:53, George Boudreau
escribió:

>   I found this tidbit of info but have not played with
it yet. To
> implement this method would require some recoding and
testing. It this
> works maybe we could add it to the experimental
release.
>
> http://www.linuxforums.org/forum/linu
x-programming-scripting/20405-error-ha
>ndling-gnu-make-sic-yes-its-possible.html

Could be a way to avoid fuser, if that already wotks 

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

Dan Nicholson wrote:
> On 6/28/06, M.Canales.es <manuellinuxfromscratch.org> wrote:
>> El Lunes, 26 de Junio de 2006 15:35, Dan Nicholson
escribió:
>>
>> > Attached is one solution that is working on my
box (so far).  The
>> > whole system is noticeably less sluggish while
building.  `top' looks
>> > normal again.
>>
>> That have a big bug: if the build of some target
fails (or you press
>> Control-C), progress-bar.sh will loop for ever in
the background.
> 
> That's why I added "rm -f /tmp/jhalfs.*"
to the traps in master.sh.
> Would that not work?
   ah.. the big question. Are the error routines defined in
'master.sh' 
inherited by 'make' and then passed to the spawned script 
'progress_bar.sh'. --Don't think so.
   Master.sh routines are definitely not available when
'make' is 
executed manually.

> 
>> I will see if we can do the exit tests each second
instead of each 120
>> milliseconds, But that could need a "sleep
1.2" instead current "sleep 
>> .25"
> 
> It just has to be a different test than running fuser. 
It
> considerably slowed down my build.  With jhalfs, 1 SBU
= 19m.  Without
> jhalfs, 1 SBU = 10m.  gcc took forever.
> 
> -- 
> Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 6/28/06, M.Canales.es <manuellinuxfromscratch.org>
wrote:
> El Miércoles, 28 de Junio de 2006 19:51, Dan Nicholson
escribió:
>
> > It just has to be a different test than running
fuser.  It
> > considerably slowed down my build.  With jhalfs, 1
SBU = 19m.  Without
> > jhalfs, 1 SBU = 10m.  gcc took forever.
>
> Ufff.. In my system there is only some seconds of
difference.
>
> We need a less intrussive way to test that make is
alive.

The numbers are a bit skewed.  I was running a gnome session
when
jhalfs was going and not without.  gnome is pretty resource
intensive
on my old box, so it slows builds.

But, yes, there needs to be a less intrusive way.  I'm sure
you guys
will think of something.  If I have
any more bright ideas, I'll let
you know. George's link looks promising.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Miércoles, 28 de Junio de 2006 20:27, Dan Nicholson
escribió:

> But, yes, there needs to be a less intrusive way.  I'm
sure you guys
> will think of something.  If I have
any more bright ideas, I'll let
> you know. George's link looks promising.

I think that a combo of your patch plus the info on that
link could to work, 
but will need a lot of code editions to can create targets
like this one


028-binutils-pass1:  022-settingenvironment
 $(call echo_message, Building) && touch $.run
 ./progress_bar.sh $ &
 -echo -e "\n`date`\n\nKB: `du -skx
--exclude=jhalfs $(MOUNT_PT)`\n" 
>logs/028-binutils-pass1 || rm $.run && false
 -PKG_PATH=`ls -t
$(MOUNT_PT)$(SRC)/binutils-2.16.1.tar.bz2 | head -n1`
&& \
 ROOT=`tar -tf $$PKG_PATH | head -n1 | sed -e 's^./;s/.*'`
&& \
 [[ -n $$ROOT ]] && \
 rm -rf $(MOUNT_PT)$(SRC)/$$ROOT && \
 if [ -e $(MOUNT_PT)$(SRC)/binutils-build ]; then \
  rm -rf $(MOUNT_PT)$(SRC)/binutils-build; \
 fi; || rm $.run && false
 -$(call unpack,binutils-2.16.1.tar.bz2) || rm $.run
&& false
 -ROOT=`head -n1 $(MOUNT_PT)$(SRC)/$(PKG_LST) | sed
's^./;s/.*'` && \
 echo "export PKGDIR=$(MOUNT_PT)$(SRC)/$$ROOT"
> envars && \
 chown -R lfs $(MOUNT_PT)$(SRC)/$$ROOT || rm $.run
&& false
 -(
time { su - lfs -c "source /home/lfs/.bashrc 
&&
/home/macana/test/jhalfs/lfs-commands/chapter05/028-binutils
-pass1" 
>>logs/028-binutils-pass1 2>&1 ; } )
2>>logs/028-binutils-pass1 && \
 echo -e "\nKB: `du -skx --exclude=jhalfs
$(MOUNT_PT)`\n" 
>>logs/028-binutils-pass1 || rm $.run
&& false
 -ROOT=`head -n1 $(MOUNT_PT)$(SRC)/$(PKG_LST) | sed
's^./;s/.*'` && \
 rm -r $(MOUNT_PT)$(SRC)/$$ROOT && \
 if [ -e $(MOUNT_PT)$(SRC)/binutils-build ]; then \
  rm -r $(MOUNT_PT)$(SRC)/binutils-build; \
 fi; || rm $.run && false
 touch  $ && rm $.run && \
 sleep .25 && \
 echo -e "\n\n "$(BOLD)Target $(BLUE)$
$(BOLD)OK && \
 echo 
------------------------------------------------------------
--------------------$(WHITE)


-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

Manuel,
   I think we should delay any serious changes until 1.0 is
released. I 
have a few ideas on cleaning up the output which may make
the necessary 
changes easier to implement. I am also looking at other
methods for 
trapping 'make' errors or finding a running process.

G.

M.Canales.es wrote:
> El Miércoles, 28 de Junio de 2006 20:27, Dan Nicholson
escribió:
> 
>> But, yes, there needs to be a less intrusive way. 
I'm sure you guys
>> will think of something.  If I have
any more bright ideas, I'll let
>> you know. George's link looks promising.
> 
> I think that a combo of your patch plus the info on
that link could to work, 
> but will need a lot of code editions to can create
targets like this one
> 
> 
> 028-binutils-pass1:  022-settingenvironment
>  $(call echo_message, Building) && touch $.run
>  ./progress_bar.sh $ &
>  -echo -e "\n`date`\n\nKB: `du -skx
--exclude=jhalfs $(MOUNT_PT)`\n" 
>> logs/028-binutils-pass1 || rm $.run
&& false
>  -PKG_PATH=`ls -t
$(MOUNT_PT)$(SRC)/binutils-2.16.1.tar.bz2 | head -n1`
&& \
>  ROOT=`tar -tf $$PKG_PATH | head -n1 | sed -e 's^./;s/.*'`
&& \
>  [[ -n $$ROOT ]] && \
>  rm -rf $(MOUNT_PT)$(SRC)/$$ROOT && \
>  if [ -e $(MOUNT_PT)$(SRC)/binutils-build ]; then \
>   rm -rf $(MOUNT_PT)$(SRC)/binutils-build; \
>  fi; || rm $.run && false
>  -$(call unpack,binutils-2.16.1.tar.bz2) || rm $.run
&& false
>  -ROOT=`head -n1 $(MOUNT_PT)$(SRC)/$(PKG_LST) | sed
's^./;s/.*'` && \
>  echo "export
PKGDIR=$(MOUNT_PT)$(SRC)/$$ROOT" > envars
&& \
>  chown -R lfs $(MOUNT_PT)$(SRC)/$$ROOT || rm $.run
&& false
>  -( time { su - lfs -c "source /home/lfs/.bashrc

> &&
/home/macana/test/jhalfs/lfs-commands/chapter05/028-binutils
-pass1" 
>>> logs/028-binutils-pass1 2>&1 ; } )
2>>logs/028-binutils-pass1 && \
>  echo -e "\nKB: `du -skx --exclude=jhalfs
$(MOUNT_PT)`\n" 
>>> logs/028-binutils-pass1 || rm $.run
&& false
>  -ROOT=`head -n1 $(MOUNT_PT)$(SRC)/$(PKG_LST) | sed
's^./;s/.*'` && \
>  rm -r $(MOUNT_PT)$(SRC)/$$ROOT && \
>  if [ -e $(MOUNT_PT)$(SRC)/binutils-build ]; then \
>   rm -r $(MOUNT_PT)$(SRC)/binutils-build; \
>  fi; || rm $.run && false
>  touch  $ && rm $.run && \
>  sleep .25 && \
>  echo -e "\n\n "$(BOLD)Target
$(BLUE)$ $(BOLD)OK && \
>  echo 
>
------------------------------------------------------------
--------------------$(WHITE)
> 
> 
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

Dan,

   This may be an inexpensive (read 'cheap') replacement
for the fuser 
fuser function . Could you try this on your machine and see
what cpu cost is

   ..Logic.. ( possibly flawed)
*  'Make' must be run from the root account or via sudo so
access to the 
/proc directory is not an issue.

*  We pick up the pid of the 'make' process whenever we
kick start the 
timer bar but from then on we only use the 'pid' for the
process status 
lookup.

  George

...inside progress_bar.sh

  # note.. DO NOT try and trace the variable makePID..
  # it changes the fuser text
makePID=$(fuser -v . 2>&1 | grep make)
makePID=$(echo $makePID | cut -d" " -f2)

write_or_exit() {

     # make has been killed or failed or run to completion,
leave
   [[ ! -e /proc/$makePID ]] && echo -n
"$" && exit

     # Target build complete, leave.
   [[ -f $ ]] && echo -n
"$" && exit

     # It is safe to write to the screen
   echo -n "$1"
}


-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page