On Thu, Jul 17, 2008 at 12:17 AM, Benjamin Huntsman
[EMAIL PROTECTED] wrote:
Has anyone gotten Nt to read/write from Venti on a Plan 9 or Linux system?
I figure one could set up something with SAMBA, but there's no native 9p for
Nt, right?
There is native 9p for Nt.
uriel
Iruata Souza wrote:
On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman
[EMAIL PROTECTED] wrote:
Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
only for the fun of it, I'm slowly trying to port it to my SGI O2.
nice! whats the status of your port? have
I could imagine that databases use mmap() havily
it's a little mystery for me why they would do that since it's slower (or ought
to be),
because the trap path and fault recovery must do more work than syscall
(perhaps much more).
it's also difficult then to optimise the replacement strategy
I now have a more-or-less unused MacBook. I'm
considering spending some time trying to get Plan 9
working on it. Has anyone gotten beyond confirming
that it won't work out of the box?
I have Plan 9 booting on an Intel Macbook. When I was
first testing it out, there were problems with the
SATA
Charles Forsyth wrote:
I could imagine that databases use mmap() havily
it's a little mystery for me why they would do that since it's slower (or ought
to be),
because the trap path and fault recovery must do more work than syscall
(perhaps much more).
it's also difficult then to
On Thu, 2008-07-17 at 10:07 +0100, Charles Forsyth wrote:
I could imagine that databases use mmap() havily
it's a little mystery for me why they would do that since it's slower (or
ought to be),
slower compared to what? I'd expect the biggest slowdown for
read()/write() be not the price
On Wed, 2008-07-16 at 22:09 -0400, erik quanstrom wrote:
On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote:
coming as no suprise, the pc port of plan 9
does work just fine with 8 cores.
mpls; cat /dev/sysstat
0 14271 21350133991116
appears not to be in dns. did i miss a change?
- erik
Edit ,x/.*/g/$/a/foo/
shouldn't this append foo after every line?
Edit ,x/.*\n/g/\n/a/foo
or
Edit ,x/.*\n/g/$/a/foo
where the latter gives a little hint about what the code might be doing
These two set of resources can be attached to each other in a number
of different ways (e.g. L1 could be the only per-core cache or L2
could also be per-core, etc.) and the job of a scheduler is to figure
out the best mapping of tasks to compute resources based on
alignment constraints. Paul
On Thu, Jul 17, 2008 at 5:41 AM, erik quanstrom [EMAIL PROTECTED] wrote:
as you've pointed out, performance-wise it's not copying vs. nothing
it's copying vs page faults and trips through the vm code.
i would think playing vm games (as linus likes to say) would make
scheduling on mp harder
On Thu, Jul 17, 2008 at 11:07, Charles Forsyth [EMAIL PROTECTED] wrote:
I could imagine that databases use mmap() havily
it's a little mystery for me why they would do that since it's slower (or
ought to be),
because the trap path and fault recovery must do more work than syscall
(perhaps
Well, depends. Non-mmap you have to do the storage management in the
app. mmap, you're using the storage management in the kernel to figure
out where the data goes, as well as all the LRU stuff to figure out
what happens when you're running out of memory and you need to get rid
of some of
On Thu, Jul 17, 2008 at 6:45 AM, erik quanstrom [EMAIL PROTECTED] wrote:
i haven't found this to be the case.
it's not always the case.
in a former life, one i'd rather forget, i did
full text search.
in order to return the full text, we had to go
get the document. due to the very
Mmap means many things to many people.
Using mmap is most often not a matter of
performance as much as it is a matter of
flexibility: being able to mmap files is about
as close as most operating systems get to
exposing the underlying page table hardware,
which lets applications that aren't
in a traditional full-featured mmap
i've noticed that some combinations of words
are scarier than others.
☺
- erik
On Jul 17, 2008, at 6:03 AM, roger peppe wrote:
Edit ,x/.*/g/$/a/foo/
shouldn't this append foo after every line?
sam gives slightly different behaviour here
(but still questionable) - it appends foo after
every empty line.
is this actually a bug, or have i misunderstood the
way that
serial is getting pretty hard to use. lots
of low-end motherboards otherwise perfect
for plan 9, either don't have serial ports or
have the irq mappings screwed up in the mp
table. i'm batting 1.000 at home with terminal/
cpu server mb with screwed-up serial.
all the machines i want to have
Can you clri the file from fossilcons?
Unfortunately, that just reports the corrupted meta data too.
Interestingly, when I started it up this morning, the check
didn't report an error with it. But then after trying to
access it, check now reports:
error: could not unpack meta block:
On Thu, Jul 17, 2008 at 2:32 AM, Anthony Martin [EMAIL PROTECTED] wrote:
I now have a more-or-less unused MacBook. I'm
considering spending some time trying to get Plan 9
working on it. Has anyone gotten beyond confirming
that it won't work out of the box?
I have Plan 9 booting on an
error: could not unpack meta block: /active/sys/src/9/pc[3]: corrupted meta
data
What does the 3 refer to? The 3rd block of the pc directory,
maybe?
Yes.
Your best bet is probably to clri /active/sys/src/9/pc
and not look back.
BTW, I had it lock up again this morning. I've noticed that
Your best bet is probably to clri /active/sys/src/9/pc
and not look back.
clri /active/sys/src/9/pc
no_lb_mode = 1 ;
It is happy now.
It's more likely in a bad loop somewhere.
Is it repeatedly doing I/O during the 100% cpu?
I don't honestly know. Next time it happens, I'll
check and see.
On Thu, Jul 17, 2008 at 5:38 AM, Kernel Panic [EMAIL PROTECTED] wrote:
Iruata Souza wrote:
On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman
[EMAIL PROTECTED] wrote:
Furthermore, does anyone out there run Plan 9 on non-x86 hardware
anymore?
only for the fun of it, I'm slowly trying to
It's more likely in a bad loop somewhere.
Is it repeatedly doing I/O during the 100% cpu?
It just locked again. Here's what I'm seeing. In
top, the first thread is using 100% of the CPU and
all the other threads are in the S state with no run
time. I don't see any indications either in
Pietro Gagliardi wrote:
9fat:
cp /sys/lib/kbmap/uk /n/9fat
try again with kbmap=uk and reboot.
Yes, I tried that but it didn't work either. This probably because it's
boot not 9load that's running at this point..
Francisco J Ballesteros wrote:
I think you need to add the map to the kernel,
In which case, this doesn't seem to be a very practical mechanism.
Wouldn't it be beter to attach to the server and then do the kbmap()
stuff ??
that's a good chicken-and-egg question. at the stage of boot
where kbmap is run, factotum has not been run and there is no
fileserver. the
andrey mirtchovski wrote:
not when you need to type your password at the console and that
password contains non-ascii characters. I believe this is the original
reason kbmap() was added in the boot code (by Francisco Ballesteros,
if my memory is correct).
Ahh yes..Good point. I confess to
Many thanks for this recipe.
For the moment, though, I am going to stick with my
cp /sys/lib/kbmap/uk /dev/kbmap in my profile
Unless there is a good reason why I shouldn't?
Bob
erik quanstrom wrote:
In which case, this doesn't seem to be a very practical mechanism.
Wouldn't it be
related to the earlier discussion, for stripping the \r at the end of
lines in windows files, i use:
,x/CR$/ c//
where CR is a cutpasted return char (yes, i could use '.' instead,
but i'm paranoid.) x doesn't seem to recognize \r as a escape
sequence. true?
related to the earlier discussion, for stripping the \r at the end of
lines in windows files, i use:
,x/CR$/ c//
where CR is a cutpasted return char (yes, i could use '.' instead,
but i'm paranoid.) x doesn't seem to recognize \r as a escape
sequence. true?
no they don't:
On Jul 17, 2008, at 8:28 PM, erik quanstrom wrote:
i suppose you could also type
ctl+m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 17, 2008, at 12:29 PM, Bakul Shah wrote:
My reasoning was that more and more
cores can be (and will be) put on a die but a corresponding
increase in off chip memory bandwidth will not be possible so
at some point memory bottleneck will
32 matches
Mail list logo
