FYI
ftp://ftp.ac.upc.es/pub/archives/gso/mach.OSF/os_coll_papers/server_colocation_design.ps
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 working on this. After your success
with the slab allocator, I'm pretty sure you're going to
Hi,
I've described some of the work I've done the past months on the wiki:
- http://www.bddebian.com/~hurd-web/user/Sergio_Lopez/
I also plan to publish a working version of memfs (a tmpfs variant
which replaces the default pager with a pool of anonymous memory) in
the next few days.
El Thu, 29 Dec 2011 19:00:21 +0100
Samuel Thibault escribió:
> Sergio Lopez, le Thu 29 Dec 2011 18:52:05 +0100, a écrit :
> > When libpager's data_return receives non-dirty data, it doesn't
> > properly release the memory that comes with the message.
>
> Just cu
Hi,
When libpager's data_return receives non-dirty data, it doesn't properly
release the memory that comes with the message.
diff -dur orig2/hurd-20111206/libpager/data-return.c orig/hurd-2006/libpager/data-return.c
--- orig2/hurd-20111206/libpager/data-return.c 2011-12-28 21:18:48.
El Thu, 29 Dec 2011 01:25:36 +0100
Samuel Thibault escribió:
> It might be biaised by the clock not being able to tick everywhere in
> the kernel (though I guess e.g. most of the IPC machinery is running
> at ipl0?), but I believe it's still a bit revealing: I had already
> noticed that ext2fs sp
El Fri, 23 Sep 2011 18:28:19 -0700
"Thomas Bushnell, BSG" escribió:
> I think the fear is of resource exhaustion, but there are so many of
> those problems, this would not be the first place to look IMO.
>
> Thomas
>
> On Thu, Sep 22, 2011 at 4:29 PM, Roland McGrath
> wrote:
>
> > The whole po
El Sun, 27 Mar 2011 12:06:03 +0200
escribió:
> Hi,
>
> On Sat, Mar 12, 2011 at 01:47:09PM +0100, Sergio Lopez wrote:
>
> > I think all of them were applied, except the ones that alter
> > default_pager's interface to accept only the creation of objects
> >
Hi,
I think all of them were applied, except the ones that alter
default_pager's interface to accept only the creation of objects with
an initial internal size of 4K.
So tmpfs should work to some degree, but probably it will have trouble
dealing with empty or large (>4K) files.
El Sat, 12 Mar 2
El Sun, 26 Dec 2010 10:27:30 +0100
Richard Braun escribió:
> Hello.
>
> From what I understand of the Hurd history, GNU Mach is based on Mach
> 4. I read that this version was intended to include the result of
> research work made at the university of Utah, the most important
> being thread migr
El Sun, 18 Jul 2010 00:47:01 +0300
Karim Allah Ahmed escribió:
> I've modified a little bit some RPCs of the current gnumach interface
> ( mainly added a new argument ) , all the changes are in
> ( [gnu-src]/include/mach/mach.defs ) , and I've
> modified the pager library accordingly.
>
> Now I
El Thu, 13 May 2010 00:15:47 +0200
Sergio Lopez escribió:
> I need some help reviewing the patch (I consider this a preliminary
> version, so there's no Changelog) and testing the stability of this
> interface. Since it requires to rebuild GNU Mach, Hurd and glibc, I'll
>
El Wed, 19 May 2010 16:29:21 +0200
Sergio Lopez escribió:
> - 01defpager-mutex.patch: Properly unlock the mutex before returning
> NO_BLOCK in pager_read_offset.
>
> - 02defpager-extread.patch: Add an "external" attribute to
> dstruct structure. In defau
El Wed, 19 May 2010 16:27:07 +0200
Samuel Thibault escribió:
> Hello,
>
> Sergio Lopez, le Fri 14 May 2010 12:35:41 +0200, a écrit :
> > I've preferred to create a new definition conditional instead of
> > using WAIT_DEBUG, since this one changes cproc_t structure siz
El Wed, 19 May 2010 23:32:37 +0200
Samuel Thibault escribió:
> Sergio Lopez, le Wed 19 May 2010 17:33:39 +0200, a écrit :
> > El Wed, 19 May 2010 16:05:27 +0200
> > Carl Fredrik Hammar escribió:
> >
> > > On Tue, May 18, 2010 at 04:19:34PM +0200, Sergio Lopez wrot
El Wed, 19 May 2010 16:05:27 +0200
Carl Fredrik Hammar escribió:
> On Tue, May 18, 2010 at 04:19:34PM +0200, Sergio Lopez wrote:
> >
> > This patch adds some padding to tmpfs_dirent structure as it's
> > suggested in the wiki
> > (http://www.gnu.org/software
El Wed, 19 May 2010 10:17:00 +0200
escribió:
> On Tue, May 18, 2010 at 04:19:10PM +0200, Sergio Lopez wrote:
>
> > This patch fixes external objects interface in mach_defpager
> > (current default pager in Hurd), so it can be used as backing store
> > by other translat
El Wed, 19 May 2010 10:37:21 +0200
escribió:
> On Tue, May 18, 2010 at 04:21:14PM +0200, Sergio Lopez wrote:
>
> > This patch modifies tmpfs to keep a reference (by mapping it into
> > its own space) to each memory object created by the user, so they
> > don't get
El Tue, 18 May 2010 16:19:34 +0200
Sergio Lopez escribió:
> Hi,
>
> This patch adds some padding to tmpfs_dirent structure as it's
> suggested in the wiki
> (http://www.gnu.org/software/hurd/hurd/translator/tmpfs.html).
>
I've taken a deeper look into this issue,
El Tue, 18 May 2010 16:33:59 +0200
Carl Fredrik Hammar escribió:
> This patch is actually on the wiki (sans the comment) (...)
Yes, I've already mentioned it.
> along with another one that fixes symlinks. Perhaps you could adopt
> that patch as well and try to get it checked in since you're al
Hi,
This patch modifies tmpfs to keep a reference (by mapping it into its
own space) to each memory object created by the user, so they don't get
inmediately terminated at the end of the current operation.
Used in conjunction with "mach_defpager: fix external objects
interface" and "tmpfs: add pa
Hi,
This patch adds some padding to tmpfs_dirent structure as it's
suggested in the wiki
(http://www.gnu.org/software/hurd/hurd/translator/tmpfs.html).
diff -du hurd-deb.orig/tmpfs/tmpfs.h hurd/tmpfs/tmpfs.h
--- hurd-deb.orig/tmpfs/tmpfs.h 2010-05-06 11:37:31.0 +0200
+++ hurd/tmpfs/tmpfs.
Hi,
This patch fixes external objects interface in mach_defpager (current
default pager in Hurd), so it can be used as backing store by other
translators (like tmpfs).diff -du hurd-deb.orig/serverboot/default_pager.c hurd/serverboot/default_pager.c
--- hurd-deb.orig/serverboot/default_pager.c 2010
El Fri, 14 May 2010 06:41:13 +0200
escribió:
> Hi,
>
> On Tue, May 11, 2010 at 11:48:12AM +0200, Sergio Lopez wrote:
>
> [...]
> > I suggest to change m_o_terminate simpleroutine, so it won't
> > transfer memory object control port receive right to the external
Hi,
It seems that some code paths in libdiskfs still leave a mutex locked
somewhere. The original WAIT_DEBUG code in libthreads records the
thread which is holding the lock, but this is not really usefull in
Hurd's translators, since that thread is probably waiting for another
message just as ever
Hi,
I've implemented a replacement for m_o_lock_request (called
m_o_sync_request) that helps to prevent thread storms in ext2fs when
synchronizing large pagers, by giving translators the ability to
throttle the amount of m_o_data_return request that are going to be
received.
When using this inter
El Wed, 12 May 2010 06:19:29 +0200
Justus Winter <4win...@informatik.uni-hamburg.de> escribió:
> On Tue, 11 May 2010 19:19:01 +0200
> Sergio Lopez wrote:
>
> > Hi,
> >
> > I think short circuiting data_unlock requests in ext2fs (by
> > allocating the pag
Hi,
I think short circuiting data_unlock requests in ext2fs (by allocating
the page in file_pager_read_page and returning it unlocked) could
improve file growing performance a bit.
I've tested it in qemu (with kvm), using "dd" to sequentially write
blocks to a file, obtaining an improvement of 10
Hello,
When a memory object is being terminated (because a change in its
"can_persist" attribute or being cleaned from cache), GNU Mach calls
memory_object_terminate. This simpleroutine, sends Mach's receive
right on memory object control port to the external memory manager. In
Hurd, a translator
El Wed, 28 Apr 2010 11:37:58 +0200
escribió:
> Hi,
>
> On Wed, Apr 28, 2010 at 07:17:30AM +0200, Karim Allah Ahmed wrote:
>
> > Is it possible to change it to 10:30 UTC [instead of 10:00 UTC] ?
>
> Yeah, that should be fine I guess...
>
> Still have no feedback from Jérémie or Sergio though :
El Tue, 20 Apr 2010 14:06:18 +0200
Samuel Thibault escribió:
> Sergio Lopez, le Tue 20 Apr 2010 13:08:32 +0200, a écrit :
> > I think you're in the right direction, but we need a broader
> > approach. Separating external pages (from externally managed memory
> > object
El Sun, 18 Apr 2010 23:28:52 +0600
Волков Максим escribió:
> I noticed that the paging starts only when the number in the free
> queue of pages is less than vm_page_free_min and continues until it
> reaches free_target. Variable vm_page_free_target is set via macro
> VM_PAGE_FREE_TARGET.
>
> #i
El Fri, 9 Apr 2010 12:09:24 +0200
Thomas Schwinge escribió:
> Hello!
>
> Sergio, great to see you're back!
>
Thanks!
> On Wed, Apr 07, 2010 at 12:37:59PM +0200, Sergio Lopez wrote:
> > To my knowledge, [...]
>
> I can't comment on your assumptions, howe
Hi,
I've found two problems with the current use of
lock_object/lock_completed in libpager:
- When a translator wants to synchroize all the contents of a pager,
it must call to pager_sync(), which in turn calls to
m_o_lock_object for the entire length of the object, and waits for
lo
El Thu, 8 Apr 2010 16:15:00 +0200
Samuel Thibault escribió:
> Sergio Lopez, le Thu 08 Apr 2010 16:07:20 +0200, a écrit :
> > In memory_object.defs, m_o_lock_request is defined as
> > simpleroutine, so a call to mach_msg_trap should only enqueue the
> > message and return
El Thu, 8 Apr 2010 13:55:33 +0200
Samuel Thibault escribió:
> Sergio Lopez, le Thu 08 Apr 2010 13:15:20 +0200, a écrit :
> > > So it's really hung in the kernel. And indeed, even if from
> > > the interface it would seem like it could be asynchronous,
> > &g
El Thu, 8 Apr 2010 00:53:02 +0200
Samuel Thibault escribió:
> HEllo,
>
> Sergio Lopez, le Wed 07 Apr 2010 12:43:15 +0200, a écrit :
> > El Sat, 27 Mar 2010 00:39:19 +0100
> > Samuel Thibault escribió:
> > > From times to times, ext2fs deadlocks on the pager->
El Sat, 27 Mar 2010 00:39:19 +0100
Samuel Thibault escribió:
> Hello,
>
> From times to times, ext2fs deadlocks on the pager->interlock mutex.
> This is an excerpt of what I could find in the process:
>
> #2 0x08106e59 in memory_object_lock_request ()
> #3 0x0806fdeb in _pager_lock_object (p=
Hi all,
Since it has been proved that throttling thread creation is not the
solution (not even a proper workaround) to prevent thread storms, I'd
like to discuss some strategies to deal with them.
To my knowledge, thread storms are usually caused by GNU Mach
continuously sending m_o_data_return r
El mié, 21-12-2005 a las 02:20 +0100, Gianluca Guida escribió:
> Hi there,
>
> On 12/20/05, Sergio Lopez <[EMAIL PROTECTED]> wrote:
> > I've written a list of tasks that I think we need to improve in GNU
> > Mach. If you find anything missing here, please feel free
Hello!
I've written a list of tasks that I think we need to improve in GNU
Mach. If you find anything missing here, please feel free to add a entry
with a short description.
http://hurd.gnufans.org/bin/view/Mach/GNUMachRevivalProject
Happy Hacking!
--
Sergio Lopez
[EMAIL PROT
intainer's decission.
3.- People who still want to work in Mach/Hurd, want to do over
gnumach-1-branch. And they would like to keep their changes into Hurd's
CVS. So until one of the maintainers recovers his interest in Mach/Hurd,
a new branch will be extremly desirable.
Thanks.
--
Se
oland (or another maintainer)
says something against it, I must assume that this rule stills in force.
Thanks!
--
Sergio Lopez
[EMAIL PROTECTED]
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
El dom, 13-11-2005 a las 18:00 +0100, Alfred M. Szmidt escribió:
>Well, it sounds like Sergio Lopez would like one; is that correct?
>
> I have no qualms with that, other than it might be hard to get the
> stuff propagated back to gnumach-1-branch/HEAD depending on how
> det
le to work in what they don't want to
work.
So there's only one feasible solution; open a new branch for GNU Mach
and GNU Hurd, and allow the people _who still want to work on Mach/Hurd_
do their own way.
Thanks.
--
Sergio Lopez
[EMAIL PROTECTED]
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
El jue, 10-11-2005 a las 00:27 +0100, Marcus Brinkmann escribió:
> At Wed, 09 Nov 2005 23:22:33 +0100,
> Sergio Lopez <[EMAIL PROTECTED]> wrote:
> >
> > El mié, 09-11-2005 a las 20:32 +0100, Marcus Brinkmann escribió:
> >
> > We don't know (since the
El mié, 09-11-2005 a las 20:32 +0100, Marcus Brinkmann escribió:
> At Wed, 9 Nov 2005 19:07:50 +0100,
> Sergio Lopez <[EMAIL PROTECTED]> wrote:
> > On the other hand, I don't think that the IBM case is applicable for us,
> > since their objetives are far different
On Wed, Nov 09, 2005 at 04:53:13PM +0100, Marcus Brinkmann wrote:
> At Wed, 09 Nov 2005 14:15:30 +0100,
> Sergio Lopez <[EMAIL PROTECTED]> wrote:
> > I've searched many times through the mailing lists, and I didn't found
> > a complete and rational discussion ab
) is incredibly valuable, even if
it _could_ (could != will) be ditched someday.
On the other hand, you can't force people to do what they don't want to
do. If the problem is that we have very low resources for development,
the solution is to try to find more (this is what the last HurdMeet
El mié, 09-11-2005 a las 09:05 +0100, Marcus Brinkmann escribió:
> At Wed, 09 Nov 2005 04:45:32 +0100,
> Sergio Lopez <[EMAIL PROTECTED]> wrote:
> >
> > El mié, 09-11-2005 a las 02:00 +0100, Marcus Brinkmann escribió:
> > > Of course, I don't speak for R
o restart working ("working" means coding, but
also testing and discussing about design issues) again on GNU Mach/GNU
Hurd to make the final effort that it needs to become a production
system (the GNU System).
Happy Hacking!
--
Sergio Lopez
[EMAIL PROTECTED]
___
ng device driver interface for
> writing drivers?
>
IMHO, user-space drivers could be a nice feature in a future (for
non-critical low-traffic devices), but right now they can't provide
nothing better than more slowness and less stability.
Happy Hacking!
--
Sergio Lopez
[EMAIL PROTECT
El dom, 28-08-2005 a las 13:44 -0700, Thomas Bushnell BSG escribió:
> Sergio Lopez <[EMAIL PROTECTED]> writes:
>
> > On my stress test (continuosly building glibc in a loop), that patch
> > keeps the number of ext2fs's threads around 200, which is a pretty sane
> &
El sáb, 27-08-2005 a las 19:52 -0700, Thomas Bushnell BSG escribió:
> Sergio Lopez <[EMAIL PROTECTED]> writes:
>
> > Oh, ok. Could you please help me to ask _all the things involved_ by
> > this...
>
> Sorry, this is now in realm of just the same generic "tell
El sáb, 27-08-2005 a las 19:10 -0700, Thomas Bushnell BSG escribió:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
>
(...)
> So, to sum up, if you have a question about design, ask a question.
> Questions are in the interrogative mood, come complete with question
> marks, and so forth.
>
Oh, ok
El sáb, 27-08-2005 a las 19:54 +0200, Marco Gerards escribió:
> Sergio Lopez <[EMAIL PROTECTED]> writes:
>
> > Sorry for bothering you, but is there some kind of "magic word" to
> > attract the attention from Hurd's Maintainers?
>
> You are not both
El mié, 24-08-2005 a las 09:16 +0300, Ognyan Kulev escribió:
> Sergio Lopez wrote:
> > El mar, 23-08-2005 a las 08:49 +0300, Ognyan Kulev escribió:
> >> IMHO In our case, it's best bugs and patches to be submitted to Savannah
> >> <http://savannah.gnu.org/proje
El mar, 23-08-2005 a las 08:49 +0300, Ognyan Kulev escribió:
> Sergio Lopez wrote:
> > This issues (there're many more, but I only took the most recent ones)
> > are still waiting for attention:
>
> IMHO In our case, it's best bugs and patches to be
8/msg00076.html
http://lists.gnu.org/archive/html/bug-hurd/2005-07/msg00278.html
http://lists.gnu.org/archive/html/bug-hurd/2005-08/msg00065.html
http://lists.gnu.org/archive/html/bug-hurd/2005-08/msg00069.html
Thanks (if someone reads this message).
--
Sergio Lo
Hello,
One of the most usual errors found by Hurd's developers is the "zalloc's
panic" one. I think that this panic could be (usually) related with the
extremly high number of threads that some translators (i.e. ext2fs)
spawn when there's a significant amount number of activity over it
(already di
U Mach tries to
access a pager with the ports previously unallocated by
object-terminate.c) the next request is waiting forever in
_pager_wait_for_seqno.
Changelog entry:
2005-08-10 Sergio Lopez <[EMAIL PROTECTED]>
* seqnos.c (_pager_stubs_update_seqno): New funct
Hello,
When a translator needs access to a portion of a memory object (i.e. in
answer for read()/write() functions), it usually must map part of that
object into its own space for later copying the data to the destination
buffer (vm_read/vm_write/vm_copy doesn't support working with
memory_objects
On Fri, 17 Dec 2004 11:09:26 +
"Neal H. Walfield" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > I've been playing a little with GNU Mach, and I think there is a
> > thing that could be nice to implement in it. In "vm/vm_fault.c",
> > when the kernel is requesting some data from a translatator for a
63 matches
Mail list logo
