linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* filesystem/kernel programmer needed for reiser4/low latency work in S.F. Bay Area (you must already have a right to work in the USA)
@ 2004-12-01 18:00 Hans Reiser
  2004-12-15  5:45 ` filesystem/kernel programmer needed for reiser4/low latency work [...] Werner Almesberger
  0 siblings, 1 reply; 2+ messages in thread
From: Hans Reiser @ 2004-12-01 18:00 UTC (permalink / raw)
  To: LKML, ReiserFS List

Pay is quite good by free software standards, and depends on level of 
experience.

I have a US customer who needs work done that involves figuring out why 
the kernel/filesystem/hard drive adds pauses that cause video glitches.  
This is much deeper and harder than you would guess, and involves 
elevator work, filesystem work, vm work, working hand-in-hand with disk 
drive vendors to do things I can't talk about here yet, etc.  There may 
be work involving block allocators optimized for streaming media, 
resizer work, repacker work, etc.

Your job will be to take as much of this task away from me (Hans Reiser) 
as you can.  You will be working with Alexander Zarochentcev and 
Vladimir Saveliev, two highly experienced linux kernel programmers, who 
will be sending you patches to apply and you will be testing and 
refining the patches (they can't get visas, and I need to work on a 
darpa project....).   The extent to which you do more than just apply 
their patches and test the result will depend on your skills.  I will be 
closely supervising your work and providing guidance.  If we can find 
someone senior for this job we will hire him, but chances are that we 
will find someone junior with potential, and make a longterm investment 
in his training.

Applicants for the job should read about reiser4 at www.namesys.com, and 
be persons who would like to contribute to that work.  The most 
important criterion will be whether you can show us well structured code 
you have written.

Hans Reiser
Namesys
www.namesys.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: filesystem/kernel programmer needed for reiser4/low latency work [...]
  2004-12-01 18:00 filesystem/kernel programmer needed for reiser4/low latency work in S.F. Bay Area (you must already have a right to work in the USA) Hans Reiser
@ 2004-12-15  5:45 ` Werner Almesberger
  0 siblings, 0 replies; 2+ messages in thread
From: Werner Almesberger @ 2004-12-15  5:45 UTC (permalink / raw)
  To: Hans Reiser; +Cc: LKML, ReiserFS List, abiss-general

Hans Reiser wrote:
> I have a US customer who needs work done that involves figuring out why 
> the kernel/filesystem/hard drive adds pauses that cause video glitches.  

Welcome to the club :-) We're working on fairly similar issues
in the ABISS project, http://abiss.sourceforge.net/

> This is much deeper and harder than you would guess, and involves 
> elevator work, filesystem work, vm work, working hand-in-hand with disk 
> drive vendors to do things I can't talk about here yet, etc.  There may 
> be work involving block allocators optimized for streaming media, 
> resizer work, repacker work, etc.

I can guess :-) Your shopping list looks similar to ours.

I think we've pretty much covered the elevator side. Our proof of
concept elevator does priorities and a number of related things.
This is synchronized with Jens' work, so these features should
eventually show up in CFQ and the block IO layer. (At which point
the ABISS elevator shall be unceremoniously scrapped.)

VM work is lined up next. So far, the most promising approach for
getting rid of VM interference seems to be to base things on the
NUMA infrastructure.

We currently support "real-time" reading from FAT, VFAT, ext2, and
ext3. There are also some scary things we can do for writing, such
as messing with the block allocation strategy (*). The latter are
currently only for FAT and VFAT.

(*) Doing file system brain surgery at this level may be a dead
    end. Just getting the various file systems to support
    reservations or an equivalent way for obtaining large
    contiguous allocations looks like a much nicer approach.

As far as doing unspeakable things with drive manufacturers is
concerned, control over defect management and thermal calibration
come to mind. Zoning and noise management details may also be of
interest.

I'm not sure how deep you really want to go there. I'd expect that
by selecting reasonably well-behaved drives and just measuring
what they do, a useful performance envelope could be determined,
that will allow you to provide adequate buffering and/or
prefetching to cover the occasional drive hickup.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-12-15  5:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-01 18:00 filesystem/kernel programmer needed for reiser4/low latency work in S.F. Bay Area (you must already have a right to work in the USA) Hans Reiser
2004-12-15  5:45 ` filesystem/kernel programmer needed for reiser4/low latency work [...] Werner Almesberger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).