|
Replies:
19
-
Last Post:
Jan 11, 2008 5:42 PM
by: rnsc
|
|
|
Posts:
7
From:
Registered:
7/7/05
|
|
|
|
/proc filesystem enhancements
Posted:
Jul 12, 2005 12:20 AM
|
|
I was thinking about some of the tuneable parameters within the OpenSolaris kernel, and thought that these should be accessible directly through the /proc filesystem, a la Linux. Is this something that would be useful to do?
|
|
|
Posts:
66
From:
IE
Registered:
6/13/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 12:44 AM
in response to: zeroboy
|
|
Hi,
What kind of tunables are you thinking about?
They are all accessible via various mechansim already,
ie rctladm, mdb, ndd etc.
Procfs in Solaris is very different from Linux, take a look
at the procfs community [1] on opensolaris, and Eric Schrocks
blogposting on the subject [2] for a bunch more details
- Fintan
[1] http://www.opensolaris.org/os/community/observability/process/procfs/
[2] http://blogs.sun.com/roller/page/eschrock/20040625#the_power_of_proc
On Tue, Jul 12, 2005 at 12:20:36AM -0700, Random wrote:
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
--
fintanr at sun dot com http://blogs.sun.com/fintanr
@dub03 http://wwws.sun.com/software/solaris/10
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
66
From:
IE
Registered:
6/13/05
|
|
|
|
|
|
Posts:
122
From:
CZ
Registered:
7/7/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 1:24 AM
in response to: zeroboy
|
|
I am against enhancement of this type.
/proc is gate to processes [/proc is a mess of many things on linux]
/dev/fd is gate to file descriptors
/etc/mnttab is gate to mounted filesystems
/devices is gate to devices
/usr/bin/sh is bourne shell
...
I think, that user do not need usualy known system config parameters (but mount, df, ps ...).
There are userland tools such as /usr/sbin/sysdef (that calls "group s-bit" /usr/sbin/i86/sysdef or /usr/sbin/amd64/sysdef to access and interpret parameters from /dev/kmem).
Programs can get some parameters with sysconfig(2) syscall.
M.C>
|
|
|
|
|
Posts:
3,783
From:
DE
Registered:
4/27/05
|
|
|
|
|
|
Posts:
3,783
From:
DE
Registered:
4/27/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 5:10 AM
in response to: zeroboy
|
|
Random <fribblefrop at yahoo dot com> wrote:
> I was thinking about some of the tuneable parameters within the OpenSolaris kernel, and thought that these should be accessible directly through the /proc filesystem, a la Linux. Is this something that would be useful to do?
It is wrong to put these parameters into /proc anyway because they don't
beling there even in a read-only way.
- Solaris supports tuneables in /etc/system since ~ 1992.
- Many of the Linux tuneables don't need to be tuned on Solaris.
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
352
From:
AU
Registered:
3/9/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 5:30 AM
in response to: joerg
|
|
On 07/12/05 13:10, Joerg Schilling wrote:
> It is wrong to put these parameters into /proc anyway because they don't
> beling there even in a read-only way.
>
> - Solaris supports tuneables in /etc/system since ~ 1992.
True, but /etc/system is not an "interface" that we're proud of. I'm not
suggesting that they belong on /proc but we don't like them in /etc/system
since that requires reboot for effect (even for those that are dynamically
tuneable), performs no range checking, can brick the system etc. The
supported tuneables (as per the guide on docs.sun.com) should be tuneable
via some tool that offers sanity checking, recovery etc.
Cheers
Gavin
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
68
From:
Registered:
6/14/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 6:17 AM
in response to: gavinm
|
|
On Tue, 12 Jul 2005, Gavin Maltby wrote:
> True, but /etc/system is not an "interface" that we're proud of. I'm not
> suggesting that they belong on /proc but we don't like them in /etc/system
> since that requires reboot for effect (even for those that are dynamically
> tuneable), performs no range checking, can brick the system etc. The
> supported tuneables (as per the guide on docs.sun.com) should be tuneable
> via some tool that offers sanity checking, recovery etc.
*BSD and Linux have sysctl(8) for this sort of stuff (applying dynamic
changes, reading current config, and / or sane editing of the respective
moral equivalents of /etc/system on each). Why not use that?
later,
chris
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
275
From:
US
Registered:
3/9/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 8:16 AM
in response to: joerg
|
|
On Tue, Jul 12, 2005 at 02:10:21PM +0200, Joerg Schilling wrote:
| Random <fribblefrop at yahoo dot com> wrote:
|
| > I was thinking about some of the tuneable parameters within the OpenSolaris kernel, and thought that these should be accessible directly through the /proc filesystem, a la Linux. Is this something that would be useful to do?
|
| It is wrong to put these parameters into /proc anyway because they don't
| beling there even in a read-only way.
|
| - Solaris supports tuneables in /etc/system since ~ 1992.
|
| - Many of the Linux tuneables don't need to be tuned on Solaris.
.. and the goal should really be zero tunables (the system should be as
self tuning as possible -- you don't set your spark timing and fuel mixture
from the dash of your car ever morning do you?). A good number of the
tunables that remain are well known are knobs into really old code that
should probably be rewritten, or is already on the chopping block.
Rightfully, PSARC has started whacking people with a big stick who try
to introduce new kernel tunables. The few tunables that do make it through
are typically now implemented within the resource controls framework,
rather than being system global, which is often too big of a hammer
(max-shm-memory is one example of this). The mere existence of tunables
in some places in the kernel (the VM and drivers being a few sore spots)
simply points out that there are gaps in the architecture that need to
be filled, rather than relying on the user to provide the glue.
Perhaps it's a difference in philosophy between Linux and Solaris..
we don't expect our users to be experts at tuning, and aim for having
things just work out of the box.
--
Eric Lowe Solaris Kernel Development Austin, Texas
Sun Microsystems. We make the net work. x64155/+1(512)401-1155
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
799
From:
Menlo Park, CA
Registered:
3/9/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 8:54 AM
in response to: elowe
|
|
On Tue, Jul 12, 2005 at 10:16:38AM -0500, Eric Lowe wrote:
>
> Perhaps it's a difference in philosophy between Linux and Solaris..
> we don't expect our users to be experts at tuning, and aim for having
> things just work out of the box.
>
Indeed, one of the more amusing stories was a Platinum Beta customer
showing us some slideware from a certain company comparing their OS
against Solaris. The slides were discussing available tunables, and the
basic gist was something like:
"We used to have way fewer tunables than Solaris, but now we've caught
up and have many more than they do. Our OS rules!"
This gave us a nice chuckle, since we've been trying hard to eliminate
every tunable we can in the past few years.
One of the best examples of this the SysV IPC tunables. Prior to S10,
these consisted of a bunch of random (though sadly well-documented)
/etc/system variables that everyone was forced to "tune" to do anything
non-trivial. Thanks to Dave Powell, a large portion of these were made
auto-tuning, and those that couldn't were turned into resource controls
as Eric described.
So if you want to add some tunables to Solaris, you should probably
pose the question as a list of things you think need tuning, and we can
help come up with a way to auto-tune them, or an appropriate interface
for managing them. And as pointed out previously, /proc is _definitely_
not the right interface.
- Eric
--
Eric Schrock, Solaris Kernel Development.
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
68
From:
Registered:
6/14/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 10:07 AM
in response to: elowe
|
|
On Tue, 12 Jul 2005, Eric Lowe wrote:
> .. and the goal should really be zero tunables (the system should be as
> self tuning as possible -- you don't set your spark timing and fuel mixture
> from the dash of your car ever morning do you?). A good number of the
> tunables that remain are well known are knobs into really old code that
> should probably be rewritten, or is already on the chopping block.
Keep in mind that there's tunables like you seem to be thinking about that
presumably can be eliminated / minimized (such as SysV IPC). However,
there's also on-off knobs that are always going to be needed --
ip_forwarding, for example, and ip_strict_dst_multihoming and all the
other networking knobs. Whether you expose that through sysctl (Linux) or
through a mixture of /etc/system and ndd (Solaris) it needs to be there.
Those sorts of networking knobs seem to be most of what I see adjusted on
customers' Linux deployments (Linux does have lots of memory knobs and
similar tunables, but they aren't used that much in practice that I've
seen; certainly no more so than they are on the Solaris boxes I see), and
at least Linux has the advantage that it provides a standard interface for
making those sorts of networking configurations permanent (sysctl.conf).
Solaris OTOH splits the stuff people care about changing between
/etc/system and the transient ndd....
later,
chris
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 11:40 AM
in response to: kaboom
|
|
> presumably can be eliminated / minimized (such as SysV IPC). However,
> there's also on-off knobs that are always going to be needed --
> ip_forwarding
actually, ip_forwarding can now be set on a per-interface basis with
ifconfig (see the "router" flag).
> for example, and ip_strict_dst_multihoming and all the other networking
> knobs.
as above, all of these knobs are moving to more specific commands (e.g.,
dladm -- and there will be others in the future). for all the reasons
already stated, the existing tunables need to either be removed or
replaced with a reasonable administrative interface. that said, this
transition will take a while.
--
meem
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
7
From:
Registered:
7/7/05
|
|
|
|
Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 5:38 PM
in response to: meem
|
|
Eliminating tuneables is a *silly* thing to do, even if the process of tuning is 'automatic'. As OS kernels and the systems they control become *far* more complex, giving the system access to dynamic tuning is a *good* thing to do. Systems undergo dynamic usage - at one point during the day, network load might be far more intense than at others, and the process load also fluctuates.
Even if the parameters are accessible to a 'daemon' like process which monitors the various subsystems, and updates the system dynamically through some kind of clean interface, be that /proc or sysctl (), or some other method. Even going to the extreme of allocating specific processors to the task of network processing, for example, when network load is *extremely* high.
|
|
|
|
|
Posts:
1,154
From:
US
Registered:
6/14/05
|
|
|
|
Re: Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 5:49 PM
in response to: zeroboy
|
|
On 7/12/05, Random <fribblefrop at yahoo dot com> wrote:
> Eliminating tuneables is a *silly* thing to do, even if the process of tuning is 'automatic'. As OS kernels and the systems they control become *far* more complex, giving the system access to dynamic tuning is a *good* thing to do. Systems undergo dynamic usage - at one point during the day, network load might be far more intense than at others, and the process load also fluctuates.
How is it silly? As an admin, I don't want to know or care about
"tunables". The system should be smart enough to Do the Right
Thing(TM), and when it doesn't, it should be considered a bug for most
tunables in my opinion. As they mentioned, they're not really
eliminating *all* tunables, some of these are just moving to other
places in the system as configuration options instead of system-wide
things.
The shm tunable are a great example of things that I never want to deal with...
--
Shawn Walker, Software and Systems Analyst
binarycrusader at gmail dot com - http://binarycrusader.blogspot.com/
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
352
From:
AU
Registered:
3/9/05
|
|
|
|
Re: Re: /proc filesystem enhancements
Posted:
Jul 13, 2005 2:04 AM
in response to: swalker
|
|
On 07/13/05 01:49, Shawn Walker wrote:
> On 7/12/05, Random <fribblefrop at yahoo dot com> wrote:
>
>>Eliminating tuneables is a *silly* thing to do, even if the process of tuning is 'automatic'. As OS kernels and the systems they control become *far* more complex, giving the system access to dynamic tuning is a *good* thing to do. Systems undergo dynamic usage - at one point during the day, network load might be far more intense than at others, and the process load also fluctuates.
>
>
> How is it silly? As an admin, I don't want to know or care about
> "tunables". The system should be smart enough to Do the Right
> Thing(TM), and when it doesn't, it should be considered a bug for most
> tunables in my opinion.
[cut]
Yes. We've seen spectacular cases of admins "tuning" and shooting themselves
in the foot. Ultimately it is our (*) fault for making them feel that
tuning is typically needed by default.
When the first system-health monitors were written and released on the
Explorer database some amazing things surfaced, such as large database
servers with maxusers set to 10 since actual unix logins were never
more than a couple of users! maxusers was used in the calculation of
just about everything, so the whole system was constrained.
Gavin
(*) "Our" as in the greater unix and unix-like OS community. Solaris has
eliminated much of the traditional need for tuning, but in releases like
2.3 and with the Cockcroft book telling all there came a tradition of
"you need to tune it".
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
799
From:
Menlo Park, CA
Registered:
3/9/05
|
|
|
|
Re: Re: /proc filesystem enhancements
Posted:
Jul 12, 2005 6:18 PM
in response to: zeroboy
|
|
On Tue, Jul 12, 2005 at 05:38:51PM -0700, Random wrote:
> Eliminating tuneables is a *silly* thing to do, even if the process of tuning is 'automatic'. As OS kernels and the systems they control become *far* more complex, giving the system access to dynamic tuning is a *good* thing to do. Systems undergo dynamic usage - at one point during the day, network load might be far more intense than at others, and the process load also fluctuates.
>
> Even if the parameters are accessible to a 'daemon' like process which monitors the various subsystems, and updates the system dynamically through some kind of clean interface, be that /proc or sysctl (), or some other method. Even going to the extreme of allocating specific processors to the task of network processing, for example, when network load is *extremely* high.
It seems like you're agreeing with what everyone else just said.
AFAICT, you're saying that dynamic tuning (in this case reacting to
network load) is the way of the future, in which case we're in total
agreement - tunables are evil.
Obviously, there are variables which change value within the kernel and
affect the behavior of the system. But this does not make them a
"tunable". A tunable is a public, documented, interface to affect the
behavior of the system. If there's a private tunenetworkload() system
call that some daemon uses, then this is exactly the interface we're
hoping to design. Maybe it goes and twiddles a dozen different
parameters in the kernel, but the point is that the kernel parameters
are never exposed. Instead, we focus on the high level utility (the
network load daemon) as the primary interface, which hopefully has no
interface at all.
If you want to discuss the programmatic method by which private
variables are set, this is a different topic (although one in which this
discussion began). I would start by referring to the discussions about
why /proc is bad choie. Maybe sysctl() is the "right" interface, but
that doesn't mean that there should be a sysctl(2) manpage declaring
them public tunables that every admin should learn to tweak
appropriately.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
7
From:
Registered:
7/7/05
|
|
|
|
Re: Re: /proc filesystem enhancements
Posted:
Jul 13, 2005 4:34 AM
in response to: eschrock
|
|
> > Even if the parameters are accessible to a
> 'daemon' like process which monitors the various
> subsystems, and updates the system dynamically
> through some kind of clean interface, be that /proc
> or sysctl (), or some other method. Even going to
> the extreme of allocating specific processors to the
> task of network processing, for example, when
> network load is *extremely* high.
>
> It seems like you're agreeing with what everyone
> else just said.
> AFAICT, you're saying that dynamic tuning (in this
> case reacting to
> network load) is the way of the future, in which
> case we're in total
> agreement - tunables are evil.
>
> Obviously, there are variables which change value
> within the kernel and
> affect the behavior of the system. But this does
> not make them a
> "tunable". A tunable is a public, documented,
> interface to affect the
Okay, gothca - I was using 'tunables' in a general
sense, ie, any parameter which is tunable, whether
that be by the system, or available directly to users
through some well defined interface.
> behavior of the system. If there's a private
> tunenetworkload() system
> call that some daemon uses, then this is exactly the
> interface we're
> hoping to design. Maybe it goes and twiddles a
> dozen different
> parameters in the kernel, but the point is that the
> kernel parameters
> are never exposed. Instead, we focus on the high
> level utility (the
> network load daemon) as the primary interface, which
> hopefully has no
> interface at all.
This is an interesting concept, which allows dynamic
'automatic' adjustment, but also has the ability to
expose an interface, *should* an expert user want to
play around with the system. What would the 'daemon'
want to know about, for example, to increase network
throughput and processing? The daemon would be able
to evaluate processes running, for example, and also
note whether processes/threads within the kernel are
getting huge amounts of device interrupts, or whether
they are allocating huge amounts of buffer space, etc.
The sheduler is excellent; scheduling is also
becoming increasingly complex. Having a 'supervisor'
would simply take some of the burden off the
scheduler, for example, when deciding which processes
should run.
One example is network traffic. This form of activity
generates large amounts of device interrupts (from the
network interfaces) which puts a *huge* burden on both
the system and the scheduler. Adaptation to massive
network load would simply be to "place the core thread
which handles network traffic onto the main CPU so
that it lessens network latency and can handle the
device interrupt and process the packet without having
to wait until another TCP/IP thread is awoken on
another processor to handle the request". The daemon
would simply monitor this kind of behaviour and have
specialised routines within it to handle specific
situations independent of the kernel - it would simply
influence the kernels behaviour without the kernel
needing to really know about it.
> discussion began). I would start by referring to
> the discussions about
> why /proc is bad choie. Maybe sysctl() is the
I can understand that /proc is quite an elegant
interface to the process subsystem and that the kernel
engineers would not like to introduce fudges into the
system.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
1,091
From:
CA
Registered:
4/27/05
|
|
|
|
Re: Re: /proc filesystem enhancements
Posted:
Jul 13, 2005 12:08 PM
in response to: zeroboy
|
|
On Wed, 13 Jul 2005, Fribble Frop wrote:
> One example is network traffic. This form of activity
> generates large amounts of device interrupts (from the
> network interfaces) which puts a *huge* burden on both
> the system and the scheduler. Adaptation to massive
> network load would simply be to "place the core thread
> which handles network traffic onto the main CPU so
> that it lessens network latency and can handle the
> device interrupt and process the packet without having
> to wait until another TCP/IP thread is awoken on
> another processor to handle the request". The daemon
I believe the new "FireEngine" TCP/IP stack in Solaris 10
already does this. I know that certianly some processor
affinity goes on.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: /proc filesystem enhancements
Posted:
Jul 13, 2005 5:08 PM
in response to: rich
|
|
> > One example is network traffic. This form of activity
> > generates large amounts of device interrupts (from the
> > network interfaces) which puts a *huge* burden on both
> > the system and the scheduler. Adaptation to massive
> > network load would simply be to "place the core thread
> > which handles network traffic onto the main CPU so
> > that it lessens network latency and can handle the
> > device interrupt and process the packet without having
> > to wait until another TCP/IP thread is awoken on
> > another processor to handle the request". The daemon
>
> I believe the new "FireEngine" TCP/IP stack in Solaris 10
> already does this. I know that certianly some processor
> affinity goes on.
yes, work was done in this area as part of fire engine and as part of nemo
(our new network driver framework), and we currently do dynamic interrupt
blanking -- check out the SQS_POLL_CAPAB handling in squeue_drain(). we
have *a lot* more upcoming work in this area underway with the crossbow
project, which sunay can fill interested folks in on (on the
networking-discuss alias).
--
meem
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
|
|
|
|
|
Posts:
130
From:
Registered:
12/20/07
|
|
|
|
Re: Re: /proc filesystem enhancements
Posted:
Jan 11, 2008 5:42 PM
in response to: meem
To: OpenSolaris » code
|
|
Please let me inject a perspective from another (non-OS) world.
In an automated system (e.g. an OS without "tunables" as discussed above), the system inputs are not controls telling the system what to do, but rather parameters that tell the system things that it cannot possibly know, such as what you like, your priorities, etc.
They present a paradigm which allows the user to leverage the automation to do the dirty work to accomplish his goals. This paradigm must be very carefully thought out with foresight so that it will remain robust and easily expandable into the indefinite future. The appropriate questions are "What are we REALLY trying to accomplish here?" "What are we likely to want to accomplish in the future?" "Assuming we are successful (else we should go home), what will the next set of issues and problems be, after *today's* problems are behind us?" "In what dimensions will the system grow?" "What new dimensions will be added"? "What does the *user* really need?" "What are *they* trying to accomplish (after all, this may be fun, but that is not why they are paying us to do this!)?"
Once these are answered, "What are the orthogonal dimensions that are appropriate BOTH to describe what we are trying to achieve, AND the implementation technology (This ensures that you have a good, implementable solution *today*)?" "What aspects of *today's* implementation technology are apt to fade away tomorrow, vs. are intrinsic in the problem space?"
All this results in a system that is elegant and gracefully absorbs future feature requests because the solution space created by the architecture is parallel to the dimensions of the true problem space. Things you never thought of, the system already [almost] [or sometimes completely] comprehends. There are an infinite number of solution spaces which will successfully intersect the problem space, but they will break painfully and require inordinate effort to grow to the extent to which they intersect (steep angle) vs. being parallel.
It is critical that the system be thoroughly thought out in this manor UP FRONT, so that the first deliverable can be a trivial, degenerate case that you can deliver quickly and reliably (and it works!), yet its capability can grow internally while remaining forward and backward compatible into the indefinite future. Plan for success, not fix-ups, modes, versions, and trap-doors later. Include versions too to accomodate your inevitable residual shortsightedness. (End of soap-box).
Yes, the system should analyse and adapt to varying conditions internally, but this does not mean that it should not have "tunable" inputs. It means that those tunable inputs should be oriented toward explaining to the system what it is trying to achieve, vs. what it should do. Its decisions may be different depending on whether you prefer to give priority to network disk accesses or local interactive processes, to manage a disk cache for maximum throughput and minimum response time, or to minimize disk usage to make the most memory available for local processes. I expect that these are mickey-mouse (though real) examples in comparison to what a serious effort would develop.
The job of the automation is then to make internal decisions (tune internal parameters if you will, but this model may not be accurate depending on implementation) to achieve what you expressed through the paradigm presented externally.
Thanks for listening. Hope it helps.
--Ray Clark
|
|
|
|
|
