Re: Asynchronous syscalls for massive concurrency
> KSE's asynchronous system calls could be used to do what you suggest > however it turns out that if you are going to do this you probably want to > do it in a way where the program is aware of what is going on, > so the ability to make all syscalls "TRANSPARENTLY ASYNCHRONOUS" is > not really a requirement. I did not mean to imply it had to be transparent; in fact that was not my goal. But I see it as a problem that, right now, if a process wishes to make n concurrent system calls (concurrent in the sense of the time period between request to response, not actually concurrent in terms of execution in the kernel or in user space), it *must* have n threads (or n co-operating processes). In other words, there is an enforcement that logical concurrency be matched with actual machine/kernel concurrency. This makes userland threading non-transparent (from the perspective of application code written in a language or framework that attempts to provide light-weight concurrency) because you can suddenly not count on all operations playing well with it. Basically, disregarding tricks that do things like offloading certain operations to separate processes (which still does not remove the n process/n thread requirement), any light-weight concurrency implementation is not generally applicable. That is, you are forced to trade trade light weight against a restricted feature set. > The async syscall part of KSE could be kept/reintroduced pretty > seperatly from the thread support part, but it really requires > someone to decide how to use it. The intended use would be to augment exiting code to take advantage of it. If it caught on among operating systems, it would be a big step forward in my opinion, from the perspective of application development. If a single or a few operating systems did it, they would have an advantage to the extent that someone actually implements the necessary support in $language_or_framework. In particular various higher level languages where it would make a huge difference to be able to support this in the interpreter/vm/core library. It would remove, or lessen, the need to differentiate between "not quite threads" and "threads" (witness stackless python tasks or ruby fibers, vs. the actual native threads in Python and Ruby 1.9; once again trading light-weight vs. generality). As far as I can see, it can be applied to the C runtime library as well, but the advantage would be less since you won't get around the need to maintain a per-thread native stack. This latter point is why I am mostly interested in it from the higher level language perspective, where higher level primitives (e.g., continuations, interpreter level stacks on the heap, etc) can be used for thread context instead of the native stack, thus removing the need to take an kbyte hit per thread just for the stack alone. It is not even mutually exclusive to native code compilation. Oh and btw, regarding my comment on paging: While as far as I can tell it holds relative to native threading, it is still not worse (better in fact) than the single-threaded state machine model where a high-latency paging operation blocks the entire process. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgpssgMFqSbEJ.pgp Description: PGP signature
Asynchronous syscalls for massive concurrency
educe contention. Many mallocs have thread-local pools
(including jemalloc). But of course, if you want to be running
with a 32 kbyte stack size, suddenly you do not have a lot of room
for thread-local resources of that type.
Having asynchronous syscalls, in combination with sufficient
support from the runtime/threading libraries, would allow for
these resources to scale with the number of *cores*, rather than
the number of threads. Even if the nature of the C language more
or less requires, as far as I can tell, that you retain a
per-thread native stack, it would be a huge plus in several
situations to be able to scale based on memory availability
relative to stack size, without worrying about secondary affects
like higher contention in malloc.
Higher level languages with native threads (e.g. Python,
Ruby 1.9, some Common Lisps):
A similar situation exists here as with C/C++.
Higher level languages without native threads (Ruby 1.8, erlang,
chicken, etc):
This is my primary motivation. Several languages attempt to get
away with using non-native threads, and end up being pretty
scalable in terms of concurrency - but at a cost. Only certain
operations are possible to do in a non-blocking fashion
(basically, I/O).
In the case of e.g. Ruby and Chicken, the problem is simply lived
with, and other syscalls block the interpreter, causing the
language to be much less usable than it otherwise would have been,
in a variety of "production" situations.
In the case of erlang, this problem is dealt with by requiring
blocking operations to be performed in a separate process, with
pretty expensive communication going on between those processes
and the core virtual machine. The fact that you can't just
randomly do your syscall, or blocking library call, right off the
bat means the threshold, in terms of effort, in interfacing with
native non-erlang code is pretty high. (Of course in erlang a
major purpose is to have this separation on purpose, to ensure
that the core virtual machine is not tained by broken native
code. I am ignoring that here.)
The reason why your call blocks the entire {Ruby,Chicken,...}
interpreter is not that somebody *wants* this to happen, but
because of the effort required to fix this problem - especially if
you are not willing to take the massive performance hit of
requireing native threads. Ruby 1.9 will have native threading,
but at a certain cost in terms of concurrency overhead, but also
in terms of language power (continuations are no longer feasable
to support).
Are asynchronous system calls just a bad idea to begin with? Am I
failing to identify major problems with this approach?[1] Is it just not
feasable at the kernel implementation level? How much of this overlaps
with KSE?
Would it be correct to say that the primary complexity in implementing
this in the kernel, stems from exactly the problem I claim with
application development - a need for additional reliance on explicit
state management, in the blocking cases where, right now, a lot is
kept implicit in the process' kernel stack?
If so I guess one could look at it as moving that problem from the
applications, to the kernel (and/or the runtime library).
[1] One problem I can think of is that one will loose concurrency in
memory access, so that the impact of high-latency paging (to/from
disk) will likely be a lot higher, since your other threads (in the
same native thread/process) will not be able to execute during said
paging. A single page-in (and to a lesser extent page-out) effectively
blocks any number of "threads".
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'
Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
pgpfFL53spVcu.pgp
Description: PGP signature
Re: threads question
>this works perfectly because I moved MGPMrUpgrade into >the same .c file so it would be a static function: > > > >structProperty* property; >pthread_t threads[NTHREADS]; >pthread_create( &threads[0], NULL, zzMGPMrUpgrade, property ); >When I use MGPMrUpgrade from a shared library the function runs >yet property isn't being passed! > What do you mean by it not being passed? Does your function receive a NULL value for the parameter instead of the pointer? (Assuming no dirty tricks, the function would by definition always be passed *some* value, though it may be NULL.) > Hmmm, should I'll try making "property" global then passing a copy of it > to each thread? I think that will guarantee it stays valid. Since you are asking about makint it global - what is it *now*? It would have to be either global, dynamically allocated, or on the stack. If it's on the stack, things are guaranteed to blow up unless the function in question is guaranteed to not terminate untill all threads are done with the data. What is the property pointer being initialized/set to? If it's dynamically allocated you should not have a problem. And I don't see how static vs. dynamic linking of libraries should matter, but perhaps I am overlooking something. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and MySQL - mysqld eats CPU alive
> I've experienced this exact problem, all the way from 4.4-STABLE as well. > The time period where the issue starts happening is very erradic, but I'm > having the exact issue on one of my servers at this very moment. I thought > it was just an issue with my box, and not anyone elses. I've seen this on two machines (both 5.2). When I built mysql with linuxthreads the problem went away. Alternatively I've seen talk of name resolution causing problems due to a non-thread-safe implementation of gethostbyname() - this too manifested itself as abnormal CPU usage. In my case --skip-name-resolve didn't help, but perhaps it might for you guys. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fsck_ffs: bgfsck fails becuase FS_UNCLEAN is not set
Hello, I am trying to track down once and for all why I never seem to be able to enjoy background filesystems on the root filesystem of any machine. I have determined that checkfilesys() in fsck_ffs/main.c is bailing at the following location, thus triggering foreground checking: if ((mntp == NULL && sblock.fs_clean == 1) || (mntp != NULL && (sblock.fs_flags & FS_UNCLEAN) == 0)) exit(7);/* Filesystem clean, report it now */ And I have confirmed that it is because (sblock.fs_flags & FS_UNCLEAN) == 0. The question is why[1]. I cannot find any code that unsets the FS_UNCLEAN flag (except ckfini()). I had expected the problem to be related to the root fs being mounted ro at that point in the boot sequence, which can be worked around. But fsck_ffs is not getting far enough to even check for that... Any pointers would be greatly appreciated. [1] The fs is in fact dirty due to a hard power-off and is detected as such when foreground checking is invoked. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2 install cd hangs on boot
> when i try to boot the freebsd install cd on my laptop (Ibm thinkpad > t40) it hangs after: > > cbb1: mem 0x5100-0x51000fff irq 11 at > device 0.1 on pci2 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [MPSAFE] I had similar problems with CardBus on the T40p. You may be interested in: http://www.scode.org/freebsdt40p.html Also freebsd-mobile is probably the better list for questions like these. I never did have trouble with the install CD though; but I ran with all PCMCIA slots empty. If you have any cards inserted, try removing them before booting the installation CD. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCM options (was Re: Where is FreeBSD going?)
> I haven't been following this too closely, so forgive me if this has > been mentioned. Does Subversion support any type of transaction based > committing? Yes. Commits are atomic. Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
