Uriel wrote:
On Wed, Jul 16, 2008 at 5:02 PM, Benjamin Huntsman
<[EMAIL PROTECTED]> wrote:
i can't agree with this label "research os" if you mean
to imply that it's not stable or somehow unfinished.
Not at all. Just meant that one doesn't run their company's Oracle database on
it.
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 fo
> 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
S
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 '$' is meant to work?
it does seem strange that in the
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 optimis
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 pri
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 2135013399
> I have Plan 9 booting on an Intel Macbook.
Is this likely to work on macbook pro as well, or is the
architecture too different?
appears not to be in dns. did i miss a change?
- erik
On Mon, 2008-07-14 at 18:12 -0400, [EMAIL PROTECTED] wrote:
> // Not just inexpensive, but also better aligned with how
> // they use compute resources (virtual vs. physical threads)
> // and memory resources.
>
> Hrm. I know about the memory/cache issues, but it sounds
> like there's more on the
>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
> > > 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 of a syscall, but what you
> pay for copyi
> 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
On Thu, Jul 17, 2008 at 2:07 AM, 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
Well, depends. Non-mmap you have to do the storage management in the
app. mmap, you're using th
On Thu, Jul 17, 2008 at 4:57 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> appears not to be in dns. did i miss a change?
nope, hang in there. It's not you.
ron
On Thu, Jul 17, 2008 at 5:40 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> what i have seen is that the intel 82598 10gbit chip, by keeping
> its tx and rx descriptor rings in cachable regular memory can
> mash the fsb to little bits. it's still pretty fast, though.
>
it's funny how often this
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 hard
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 '$' i
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
> (
On Thu, Jul 17, 2008 at 2:07 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> ,x/$/a/foo/
i was actually trying to do something slightly different;
my original command was:
,x/^[ \t]*let.*/v/in$/a/ in/
and i worked around it by doing
,x/^[ \t]let.*\n/v/in\n/x/\n/i/ in/
which wasn't too ba
> 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
> But you make trips through the vm code on read/write in any event,
> don't you? There was a pretty good paper comparing these paths once
> and in the end it boiled down to "your cost will vary depending on how
> you wrote the kernel" :-)
on plan 9? where?
- erik
Paweł Lasek wrote:
A much more important reason might be the fact that memory mapping of
files is only one function of mmap() and company. Basically when you
have mmap() and munmap() you can write your own allocator (which might
be very useful, especially for databases). I won't delve into using
On Thu, Jul 17, 2008 at 6:46 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> But you make trips through the vm code on read/write in any event,
>> don't you? There was a pretty good paper comparing these paths once
>> and in the end it boiled down to "your cost will vary depending on how
>> you wr
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 ve
On Thu, 2008-07-17 at 05:55 -0700, ron minnich wrote:
> Looking at the Plan 9 exec path it's hard to see a reason that Plan 9
> could not do mmap, it just doesn't. But lots of code nowadays depends
> on mmap being there. Is there something I'm missing?
I've commented privately to Erik that this is
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 happ
> 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 misunder
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 ser
> 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: /active/sys
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 booti
> 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
> 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 se
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
> 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 vmst
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,
>> I think you need to add the map to the kernel, as a root file so that
>> boot could find it before reaching the file server.
>>
>
> 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 ??
not when you nee
> 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 adva
On Tue, 15 Jul 2008 10:50:46 PDT Paul Lalonde <[EMAIL PROTECTED]> wrote:
>
> On 15-Jul-08, at 1:01 AM, Bakul Shah wrote:
> >
> > I suspect a lot of this complexity will end up being dropped
> > when you don't have to worry about efficiently using the last
> > N% of cpu cycles.
>
> Would that I w
I know a lot of folks on this list like history, so check this one out:
http://www.fas.org/sgp/othergov/doe/lanl/docs1/LA-6943-H.pdf
" Further-
more, by using clip leads to short one side of the
vacuum-tube flipflops, you could actually change
the co
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 havi
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
> 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?
as long as you're happy with it, and don't mind the gotcha,
i don't see that it would be a problem.
related to the earlier discussion, for stripping the \r at the end of
lines in windows files, i use:
,x/$/ c//
where is a cut&pasted 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/$/ c//
>
> where is a cut&pasted 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: sam
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 preven
49 matches
Mail list logo
