Re: Reworking libpager.

2012/6/3 Neal H. Walfield : > Hi, Максим, > > If I didn't post the patches, then either I never wrote them or they > have been lost.  Sorry. > OK. Just wanted to be sure that I'm not redoing your work. -- Regards, Maksym Planeta.

[bug #32755] tmpfs crashes on filling an empty file

Update of bug #32755 (project hurd): Status: In Progress => Fixed ___ Reply to this item at: ___ Messag

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sun 08 Apr 2012 01:28:48 +0300, a écrit : >> No, it isn't bogus and should work, but as it is hack that relies on >> implementation and how it works is not obvious (at least from my point >> of view), I decided to disabl

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sun 08 Apr 2012 00:48:18 +0300, a écrit : >> > Existing conditions, agreed. But the conditions you introduce are about >> > one-level only. >> >> Really, but I can replace 3 conditions from the beginning of commit wi

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sun 08 Apr 2012 00:17:43 +0300, a écrit : >> Samuel Thibault writes: >> > Maksym Planeta, le Sat 07 Apr 2012 23:20:13 +0300, a écrit : >> >> > No: as I said, allocate an empty map, so that the existing code can poke

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sat 07 Apr 2012 23:20:13 +0300, a écrit : >> > No: as I said, allocate an empty map, so that the existing code can poke >> > at it without testing for its presence or not. >> > >> >> Purpose of this conditi

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sat 07 Apr 2012 21:42:04 +0300, a écrit : >> Samuel Thibault writes: >> >> > Maksym Planeta, le Sat 07 Apr 2012 19:51:56 +0300, a écrit : >> >> Here is initialization code from pager_alloc(): >&

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sat 07 Apr 2012 19:51:56 +0300, a écrit : >> Here is initialization code from pager_alloc(): >> if (INDIRECT_PAGEMAP(size)) { >> alloc_size = INDIRECT_PAGEMAP_SIZE(size); >>

Re: tmpfs status

that you raised some >> > time ago? >> >> No, this means that I should support both formats, because old one is >> used by kernel. And new one is needed because new page attributes are >> needed. So since this commit both interfaces are supported. > > That's actually what I meant. You should probably rather fold it into > the patch that moves the code from _data_write to _data_return > OK. Regards, Maksym Planeta.

Re: Setting behavior for clustered IO

Richard Braun writes: > On Mon, Apr 02, 2012 at 08:43:41PM +0300, Maksym Planeta wrote: >> Sergio Lopez writes: >> > Instead of implementing a new call, I think >> > memory_object_change_attributes should be extended to support setting >> > the cluster si

Re: Setting behavior for clustered IO

Sergio Lopez writes: > El Mon, 02 Apr 2012 00:23:03 +0300 > Maksym Planeta escribió: > >> >> Hello, >> >> I want to work upon implementing of clustered page reading in >> GNU/Mach, as GSoC project. > > I'm happy to know that you will be w

Setting behavior for clustered IO

ers which could be used to inform kernel about direction of reading. Am I right or is it better to do like kam was doing? Regards, Maksym Planeta.

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Wed 28 Mar 2012 20:42:07 +0300, a écrit : >> Samuel Thibault writes: >> >> > Ideally you should try to put a whole Hurd system on it, so >> > we can use it for liveCD and installer. >> >> Do you mea

Re: tmpfs status

Thomas Schwinge writes: > Hi! > > On Wed, 28 Mar 2012 23:41:57 +0300, Maksym Planeta > wrote: >> Thomas Schwinge writes: >> > On Wed, 28 Mar 2012 22:40:22 +0300, Maksym Planeta >> > wrote: >> >> Samuel Thibault writes: >> >> &

Re: tmpfs status

s much > better. > Ok. I'll add new field in dirstat that stores if diskfs_lookup_hard was called with type RENAME for '..' directory. > Thanks for your work, and looking forward your updated patches. > Samuel How have I make updated patches? Amend old ones, revert them and then make new patches, but already right or just make patches that correct present errors? Thank you for review, Maksym Planeta.

Re: tmpfs status

Thomas Schwinge writes: > Hi! > > On Wed, 28 Mar 2012 22:40:22 +0300, Maksym Planeta > wrote: >> Samuel Thibault writes: >> >> > Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écrit : >> >> > 1. >> >> > http://git.s

Re: tmpfs status

er? And what types of archives should be supported? Regards, Maksym Planeta.

Re: tmpfs status

It performs random IO operations on specified file. Regards, Maksym Planeta. 1. http://codemonkey.org.uk/projects/fsx/

Re: tmpfs status

50m5s ext2fs42m4s tmpfs 42m32s New thing also was that I typed commands directly on the machine, and not using ssh, like before. So, behaviour didn't change: ramfs+ext2 is the slowest, ext2fs and tmpfs work approximately with same speed. Regards, Maksym Planeta.

Re: tmpfs status

formance/degradation/> No, I'll do tests again, but I'll be able only in evening. Anyway, pure ext2fs test was the last. >> 1. >> http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/master > > Someone to review the patches... :-/ > This time they are formatted much better than I was doing it with allocator. At least I tried :) Regards, Maksym Planeta.

tmpfs status

Hello, I'm currently working on getting tmpfs work on the Hurd. I already asked on IRC to make or suggest some test for tmpfs. Last time Thomas Schwinge suggested me to compile packages and thanks to that a found some bugs. Now they are seems to be fixed, so I ask once more to make/suggest some

[bug #35501] Work with memory object before it is initiated hangs the kernel.

Update of bug #35501 (project hurd): Open/Closed: Closed => Open ___ Follow-up Comment #1: I closed this bug. But it seems to me that I was wrong. With new defpager this bug just changed beh

[bug #19426] GNU Mach: panic: zalloc: zone kalloc.8192 exhausted

Follow-up Comment #2, bug #19426 (project hurd): Probably, as mach uses new allocator now, this bug could be closed? ___ Reply to this item at: ___ Mess

[bug #35501] Work with memory object before it is initiated hangs the kernel.

Update of bug #35501 (project hurd): Status:None => Invalid Open/Closed:Open => Closed Wiki-like text discussion box: => Bug is present only with defpager, I work on.

[bug #35501] Work with memory object before it is initiated hangs the kernel.

Additional Item Attachment, bug #35501 (project hurd): File name: test.shSize:0 KB ___ Reply to this item at: ___ Message sent

[bug #35501] Work with memory object before it is initiated hangs the kernel.

URL: Summary: Work with memory object before it is initiated hangs the kernel. Project: The GNU Hurd Submitted by: mplaneta Submitted on: Fri 10 Feb 2012 08:53:19 PM EET Category: None

[bug #35293] [ext2fs] cat on directory

Update of bug #35293 (project hurd): Status:None => Invalid Open/Closed:Open => Closed Wiki-like text discussion box: => ___

[bug #35293] [ext2fs] cat on directory

Update of bug #35293 (project hurd): Wiki-like text discussion box: => ___ Follow-up Comment #4: Anyway there shouldn't be these characters: "@Ô". And should be n after mcsim (Now there is no o

[bug #35293] [ext2fs] cat on directory

URL: Summary: [ext2fs] cat on directory Project: The GNU Hurd Submitted by: mplaneta Submitted on: Thu 12 Jan 2012 12:32:21 AM EET Category: None Severity: 3 - Normal

[bug #32755] tmpfs crashes on filling an empty file

Follow-up Comment #3, bug #32755 (project hurd): Thomas, exactly filling of empty file works. But I'm going to close this bug when all errors I find in tmpfs will be fixed. Just to not open new bugs. ___ Reply to this item at:

Re: Braun/Planeta slab allocator (was: GNU Hurd development blog: 2011-q3)

Difference isn't big, but I disagree that it's just a noise, because this difference is systematic and constant in some range. At least according to tests that I made in September, but your results don't disprove it. Here are my results for "time ( cd gnumach−1* && dpkg−buildpackage)": slab zalloc 38m28.290s 38m58.400s 38m38.240s 38m42.140s 38m30.410s 38m52.920s -- Thanks, Maksym Planeta

symlink support in tmpfs

Hello. Here was a patch by Ben Asselstine[1], which fixes symlinks in tmpfs. Why wasn't it applied into master branch? 1) http://thread.gmane.org/gmane.os.hurd.bugs/11829/focus=12098 -- Thanks, Maksym Planeta

Re: Fixing tmpfs and defpager

e. It's idea is using pager_request port from ds structure, instead of pager_request, which was supplied by caller (here translator), for external memory objects. -- Thanks, Maksym Planeta

Fixing tmpfs and defpager

tique. -- Thanks, Maksym Planeta >From 060c22d8fa2960ee53263669db1c6bcb2146fedd Mon Sep 17 00:00:00 2001 From: Maksym Planeta Date: Sun, 13 Nov 2011 23:04:13 +0200 Subject: [PATCH] Fix defpager and tmpfs to make reading/writing in tmpfs work. * hurd/default_pager.defs (default_pager_obj

tmpfs compilation

*** [tmpfs] Error 2 Than I refused my changes, but tmpfs didn't compile until I ran "make clean". -- Thanks, Maksym Planeta

Re: tmpfs for Maksym Planeta

y error. Than I tested it on ext2fs, mounted on ramdisk. Everything worked too. NFS I do later, but as can be seen fsx works. -- Maksym Planeta

[PATCH] gnumach: vm: zone_gc: Got rid of useless function

when kmem_free is called, but investigating of code and test didn't reveal the deadlock. Signed-off-by: Maksym Planeta --- kern/zalloc.c | 95 +++-- 1 files changed, 38 insertions(+), 57 deletions(-) diff --git a/kern/zalloc.c b/kern/zall

Memory management for Gsoc

/savannah.gnu.org/task/?5489: >We need a new design to the Virtual Memory system, and Mach based ones >are not a good idea for microkernels. So, vm system should be redesigned. Can you advise me what way it can be redesigned, if you have such ideas. And can it be part of Gsoc project? -- Thanks, Maksym Planeta

[PATCH] gnumach: kalloc: Zone determining and constants optimization

Variables, which change their value only once, by the initialization were defined as macros. Routine for determining zone for object depends of object size. Since zone sizes are powers of two this routine was optimized. On x86 proceessors will be used bsr instruction. Signed-off-by: Maksym

Re: [PATCH] gnumach: kern: kalloc optimization for constant size requests

I'm very sorry, this patch doesn't work. I've sent it by mistake. I'll resend it later. -- Thanks, Maksym Planeta

[PATCH] gnumach: kern: kalloc optimization for constant size requests

n't change their value after initialization where added const specifier. Signed-off-by: Maksym Planeta --- kern/kalloc.c | 80 + kern/kalloc.h | 103 +++- kern/zone_sizes.h | 17 +