Re: [9fans] duppage
On Sun Jun 8 14:17:16 EDT 2014, quans...@quanstro.net wrote:
On Sun Jun 8 13:55:52 EDT 2014, cinap_len...@felloff.net wrote:
right. the question is, how did it vanish from the image cache.
i think it is in the image cache, but .ref 1.
perhaps independent of your question,
my assumption is correct, and proven.
the problem was that pagereclaim() only looked through
pga.pgsza[0], but since 2MiB pages were introduced in nix,
no pages could ever be reclaimed this way, since they would
be in pga.pgsza[1].
i don't think this really addresses your question, or my
original problem though. the corrected version which i think
should work for any architecture is below. i intend to
incorporate charles locking changes later on.
(lock(lga.pgsza[lg]) instead of the whole thing.)
i think those changes (in the 9atom /sys/src/9 kernels)
are good stuff.
- erik
---
/*
* Called from imagereclaim, to try to release Images.
* The (ignored) argument indicates a preferred image for release.
*/
void
pagereclaim(Image*)
{
int lg, n;
usize sz;
Page *p;
lock(pga);
/*
* All the pages with images backing them are at the
* end of the list (see putpage) so start there and work
* backward. Assume the smallest page size (BOTCH).
*/
sz = 0;
n = 0;
for(lg = 0; lg m-npgsz; lg++)
for(p = pga.pgsza[lg].tail; p != nil; p = p-prev){
if(p-image != nil p-ref == 0 canlock(p)){
if(p-ref == 0) {
n++;
sz += 1m-pgszlg2[lg];
uncachepage(p);
}
unlock(p);
if(sz = 20*MiB n5)
break;
}
}
unlock(pga);
}
[9fans] long paths in acme tags
If you are editing multiple file within the same directory with a very long path, the long dir paths is what takes up most of the tag. One idea (borrowed from zsh) is to assign a long path to a variable and then just show the variable instead. Thus for example, given long paths like these: /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file1 /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file2 If one can define a variable in acme foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Has anyone considered doing this or is there a better idea? I suppose on plan9 one can use bind for this but on p9p things get considerably clunkier (9p, fuse...) when a variable can do the job more simply.
Re: [9fans] long paths in acme tags
On Wed Jun 11 15:56:59 EDT 2014, ba...@bitblocks.com wrote: If you are editing multiple file within the same directory with a very long path, the long dir paths is what takes up most of the tag. One idea (borrowed from zsh) is to assign a long path to a variable and then just show the variable instead. Thus for example, given long paths like these: /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file1 /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file2 If one can define a variable in acme foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Has anyone considered doing this or is there a better idea? I suppose on plan9 one can use bind for this but on p9p things get considerably clunkier (9p, fuse...) when a variable can do the job more simply. this was done in wily in the mid 90s, complete with an algorithm to find the shortest representation. - erik
Re: [9fans] long paths in acme tags
If one can define a variable in acme foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Has anyone considered doing this or is there a better idea? I suppose on plan9 one can use bind for this but on p9p things get considerably clunkier (9p, fuse...) when a variable can do the job more simply. this was done in wily in the mid 90s, complete with an algorithm to find the shortest representation. What was the result? In which distribution is it available? How is it used? sl
Re: [9fans] long paths in acme tags
On Wed Jun 11 16:14:54 EDT 2014, s...@9front.org wrote: If one can define a variable in acme foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Has anyone considered doing this or is there a better idea? I suppose on plan9 one can use bind for this but on p9p things get considerably clunkier (9p, fuse...) when a variable can do the job more simply. this was done in wily in the mid 90s, complete with an algorithm to find the shortest representation. What was the result? In which distribution is it available? How is it used? wily was a stand-alone unix program. iirc it relied on the frame library port from plan 9. it worked, but the problem was that environment variables are not understood by the kernel. google wily text editor. - erik
Re: [9fans] long paths in acme tags
this was done in wily in the mid 90s, complete with an algorithm to find the shortest representation. What was the result? In which distribution is it available? How is it used? wily was a stand-alone unix program. iirc it relied on the frame library port from plan 9. Sorry, my fault, I somehow missed wily in your original reply. sl
Re: [9fans] long paths in acme tags
if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Real paths are plumbable and copyable, variable names are not. p9p acme (where this problem is more acute) has multiline tags. -- Aram Hăvărneanu
Re: [9fans] long paths in acme tags
On Wed Jun 11 16:34:51 EDT 2014, ara...@mgk.ro wrote: if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Real paths are plumbable and copyable, variable names are not. p9p acme (where this problem is more acute) has multiline tags. both of these issues can be sorted. there's no reason the cut text or plumb'd text need equal the displayed text. but one would need to be very careful about it. - erik
Re: [9fans] long paths in acme tags
On Wed, 11 Jun 2014 22:33:07 +0200 =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= ara...@mgk.ro wrote: if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Real paths are plumbable and copyable, variable names are not. p9p acme (where this problem is more acute) has multiline tags. Multiline tags don't help with the clutter. In any case I am only talking about what is displayed in the tag. I have never need to plumb the tag. Valid point about copying but you can deal with that by defining similar variables in rc. Thanks Erik, I will take a look at wily code.
Re: [9fans] long paths in acme tags
Whenever they are available, I use symlinks for shortening paths for Acme. This is so far the only good use I've found for them ;-) Robby On Jun 11, 2014 8:54 PM, Bakul Shah ba...@bitblocks.com wrote: If you are editing multiple file within the same directory with a very long path, the long dir paths is what takes up most of the tag. One idea (borrowed from zsh) is to assign a long path to a variable and then just show the variable instead. Thus for example, given long paths like these: /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file1 /a/very/very/very/very/very/very/very/very/very/long/path/to/a/file2 If one can define a variable in acme foo=/a/very/very/very/very/very/very/very/very/very/long/path/to/a if the acme tags show $foo/file1 $foo/file2 it would be much nicer. Has anyone considered doing this or is there a better idea? I suppose on plan9 one can use bind for this but on p9p things get considerably clunkier (9p, fuse...) when a variable can do the job more simply.
Re: [9fans] long paths in acme tags
On Wed Jun 11 17:34:33 EDT 2014, ba...@bitblocks.com wrote: On Wed, 11 Jun 2014 22:27:34 BST Robert Raschke rtrli...@googlemail.com wrote: Whenever they are available, I use symlinks for shortening paths for Acme. This is so far the only good use I've found for them ;-) Symlinks don't help in the tag as pwd finds the real path. real path? hmmm. symlinks aren't fake. :-) - erik
Re: [9fans] long paths in acme tags
On 11/06/2014 23:32, Bakul Shah wrote: On Wed, 11 Jun 2014 22:27:34 BST Robert Raschke rtrli...@googlemail.com wrote: Whenever they are available, I use symlinks for shortening paths for Acme. This is so far the only good use I've found for them ;-) Symlinks don't help in the tag as pwd finds the real path. Which pwd are you talking about? GNU's pwd does not resolve symlinks (pwd -P does), nor p9p's acme. Nicolas
[9fans] Semaphores in Plan 9
in Semaphores in Plan 9 [1] a test is described comparing semaphore-based locks to tas-based spinlocks. the paper says they ran doug's power series program using the different lock types in libthread for channels. i was trying to reproduce the results in the test, and my naive attemps don't fare well for semaphores. so, is the test code available anywhere? or has anyone written a comparable benchmark which favors semaphore-based locks? [1] http://doc.cat-v.org/plan_9/IWP9/2008/semaphores.pdf pgpdFDOEoAIqe.pgp Description: PGP signature
Re: [9fans] Semaphores in Plan 9
On Wed Jun 11 20:26:49 EDT 2014, misch...@9.offblast.org wrote: in Semaphores in Plan 9 [1] a test is described comparing semaphore-based locks to tas-based spinlocks. the paper says they ran doug's power series program using the different lock types in libthread for channels. i was trying to reproduce the results in the test, and my naive attemps don't fare well for semaphores. so, is the test code available anywhere? or has anyone written a comparable benchmark which favors semaphore-based locks? i don't have the power series code, but... i spent quite a bit of time on this issue, and generally semaphore based locks look quite bad. the reason is very simple. the syscall takes ~1µs. the hazards protected by locks aren't generally this big. a µs is a long time. there's another reason that's subtle, and makes analysis hard. the semaphores are fair, while the user-level tas locks are grossly unfair. that unfairness inflates the operations per second because one processor keeps reacquiring the lock, while others lose out. so it's like running the program n times sequentially, rather than running concurrently on n processors. i'm not sure what the answer is. - erik
[9fans] [GSOC] port forwarding
Hi all, I run into a situation that may need to setup the port forwarding rule, but not quite sure. Hope you guys can provide some suggestions. Thanks in advance! Basically, I have a virtual machine (KVM) working as plan9's fs+auth server. The auth+fs server listens the port 564 and uses NAT (network address translation) to connect to the Internet. The virtual machine runs on a Linux box. On the same Linux machine, I use qemu to execute an enhanced plan9 cpu server (with new features included). The qemu instance needs to boot from the auth+fs server. My question is, to make the boot successful, do I need to set any port forwarding rules? If so, how to do that? -- Think big; Dream impossible; Make it happen.
