at system call used
by gprof'ed executable take in account only a thread so results can be not
completly significative. A mono thread (or bi-thread) server can help in
profile it, it would better than nothing.
PS: I've also already post some results and comparison of hurd vs
in the ext2fs translator, I found that caching of
data is often inconsisten. I mean, rerunning the same test program that made
always the same file access, sometimes made disk access and sometimes not.
I always wondered why...
--
Saluti / Regards
Diego Roversi |
.
Have you take a look to SuperVGATextMode? It is a nice program for linux,
that can change text mode programming the VGA. You probably find a lot of
information about programming text mode for VGA & superVGA.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
rd, and skipping this error, it booted hurd,
but Hurd dies with messages about ipc timeout. I suppose that Hurd is
sensible to *very* slow PC, like the emulated one.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
_
d with a
"substore" that can shrink or grow at will. That happens because you can't
know how well data can be compressed. The only way to handle correctly is to
compress the data at fs layer (see e2compress: a modified ext2).
--
Saluti / Regards
Diego Roversi | diegor at maga
2;
pdma_water_mark[B9600] = i;
pdma_water_mark[EXTA] = i; /* >14400 baud */
pdma_water_mark[EXTB] = i; /* >19200 baud */
pdma_water_mark[B57600] = i;
pdma_water_mark[B115200] = i;
-
+#endif
+
return;
}
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
when exit() is invoked,
after the reply. For this reason I call _mcleanup() before reply, and rename
the file to avoid that a gmon.out to be overwritten when _mcleanup() is
called a second time from inside exit(). For some misterius reason sleep
helps also...
Thank you.
--
Saluti / Regards
necessary, btw before running gprof,
remember to rename back gmon.out to gmon.out. The _mcleanup() forces the
process to produce the gmon.out file.
That's all folk.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
___
.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
see the stack of the offending thread, but I
can't use step and next command, they work like continue. The only way is to
set a lot of breakpoint in the target function, but maybe I'm still
missing something.
TIA.
--
Saluti / Regards
Diego Roversi | diegor at mag
ng very similar to my suggested function.
TIA.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
from disk. Of course I'm
pleanty of free RAM. Bigger file (16Mb) is always reread from disk.
I hope that some gnumach/hurd expert can explain this strange behaviour.
TIA
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
bytes_wanted: int;
out data: io_buf_ptr_t
);
But I don't understand why there are two arguments: recnum and bytes_wanted.
Only one of them is not enough? There is some documentation somewhere about
this system call?
TIA
---
Saluti / Regards
l
> mmapping mechanisms can be improved to cache better?
I think so. Beside of the limit of device size, mmaping the device is the
more efficient and elegant solution. For example in this way phisic memory can be
fairly used among process and caching data, instead of having a fixed size
cache in st
w integrate the cache in storeio/libstore.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
e storeio.
Any suggestion?
TIA
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
an be
useful implementing caching, for example, in the storeio translator?
I've also noted that during compiling hurd, there is a lot free memory
avaible, so why don't we use it?
TIA.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor a
pdma_water_mark[B57600] = i;
pdma_water_mark[B115200] = i;
-
+#endif
+
return;
}
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
O water_mark is how much incoming data is collected before
being processed. I don't understand why water_mark must decrease at higher
speed. BTW the values for speed of 38400 or greater was found out with some
experiments.
That's all for the moment...
--
Saluti / Reg
a to
the application level?
TIA,
Diego Roversi.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
20 matches
Mail list logo