Enclaves were supposed to be an exception to this rule. First, SRB's in an
enclave are interruptible. Second, for dispatching purposes, SRB's and
TCB's placed in an enclave are excluded from the address space. The system
will select either an enclave or address space for processing. Time
On Sunday, November 3, 2019, 05:38:02 AM PST, Peter Relson
wrote:
> all other things being equal, ready tasks within in address space are >
> dispatched in a round-robin fashion. A time slice is a time slice.
Enclaves were supposed to be an exception to this rule. First, SRB's in an
> If the two parties are running in different address spaces then a
> complaint could only be that the address space is consuming a lot of
CPU
> and that is exactly what WLM goals and priorities are for.
Only true if you ignore mixed workload address spaces
Perhaps you did not read that my
On Wednesday, October 30, 2019, 05:50:04 AM PDT, Peter Relson
wrote:
,> If the two parties are running in different address spaces then a
> complaint could only be that the address space is consuming a lot of CPU
> and that is exactly what WLM goals and priorities are for.
Only true if
>I believe the OP mentioned he received complaints that his
>task was hogging the CPU.
I went back and looked. The OP said no such thing
One of the posters (I thought the OP) mentioned that they were just trying
to be a good guy, amidst a lengthy period of intensive CPU usage, of
trying to
Thomas David Rivers wrote:
Does anyone happen to know the best way for a running task
to give up running and let another task run?
But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.
Sorta like "I'm done for
On Tue, 29 Oct 2019 17:43:25 +, Jon Perryman wrote:
>I believe the OP mentioned he received complaints that his
>task was hogging the CPU.
I went back and looked. The OP said no such thing. In fact, the
OP has said nothing about why he wants to do this, despite
being asked no less than
I believe the OP mentioned he received complaints that his task was
hogging the CPU.
It would be unusual for "someone" to get complaints from "someone else"
about a task owned by that "someone", unless both the "someone" and the
"someone else" were running in the same address space at the
On Wed, 23 Oct 2019 18:23:31 +, Seymour J Metz wrote:
>The Dispatcher has been using timers for decades. What interrupts your
>code is an external event from a timer or from a SIGP on another CPU.
>If you're running with appropriate goals, don't try to second guess WLM.
I believe the OP
On Wed, 23 Oct 2019 18:23:31 +, Seymour J Metz wrote:
>The Dispatcher has been using timers for decades. What interrupts your
>code is an external event from a timer or from a SIGP on another CPU.
>If you're running with appropriate goals, don't try to second guess WLM.
I agree. The OP has
The Dispatcher has been using timers for decades. What interrupts your code is
an external event from a timer or from a SIGP on another CPU.
If you're running with appropriate goals, don't try to second guess WLM.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
External Interrupt has always been a grab bag, even on S/360. S/370 added more
events that I wouldn't describe as external. The list is pretty long these days.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
If you use your own spin loop (as opposed to a spin lock) and the lock is held
by another task, then dispatching delays for that task will delay you, driving
up the CPU consumption. The Devil is in the details, but I have yet to see a
case where it is warranted.
What I have seen is a case
Thank you Peter for the great comments!
On 2019-10-23 8:34 PM, Peter Relson wrote:
The code snippets I posted show that the code sleeps rather than waiting
to be signaled which I suspect may be cheaper on those platforms.
I don't know about the relative cheapness, but generally sleeping (and
The code snippets I posted show that the code sleeps rather than waiting
to be signaled which I suspect may be cheaper on those platforms.
I don't know about the relative cheapness, but generally sleeping (and
looking again when you wake up) is easier, and waiting/posting
(pausing/releasing)
Thank you, Don!
On 2019-10-22 8:37 PM, Don Poitras wrote:
And for things like "enabled resources" (ENQ, LOCAL lock), the system may
attempt to manage the work unit priorities to give the "holder" some extra
CPU time.
This is interesting for ENQ. Windows has a mechanism in place to raise
the
In article you wrote:
> On 2019-10-22 7:42 PM, Peter Relson wrote:
> > You can spin for a while, but then really need to "wait" (or pause) until
> > "posted" (or released) when the resource becomes available..
> The code snippets I posted show that the code sleeps rather than waiting
> to be
On 2019-10-22 7:42 PM, Peter Relson wrote:
You can spin for a while, but then really need to "wait" (or pause) until
"posted" (or released) when the resource becomes available..
The code snippets I posted show that the code sleeps rather than waiting
to be signaled which I suspect may be
My advice: Do Not Spin.
If your implementation of a "lock" is to loop until it is available, you
are pretty much doomed to failure in some edge cases over which you likely
have no control.
You can spin for a while, but then really need to "wait" (or pause) until
"posted" (or released) when
On 2019-10-22 12:09 PM, Mike Hochee wrote:
Define application program? COBOL batch or CICS transaction program?
Most legacy applications on z/OS don't implement concurrency.
Agreed, they don't implement concurrency, however they are often very heavily
reliant upon on it, as it is built into
> Define application program? COBOL batch or CICS transaction program?
> Most legacy applications on z/OS don't implement concurrency.
Agreed, they don't implement concurrency, however they are often very heavily
reliant upon on it, as it is built into the database management and message
On 2019-10-22 1:55 AM, Tony Harminc wrote:
On Sun, 20 Oct 2019 at 02:32, David Crayford wrote:
The only code I've seen that implements yield are synchronization
routines. Consider a spin-lock which is spinning on a CS instruction.
Why would any application program on z/OS implement and use a
On Mon, 21 Oct 2019 19:01:15 +, Jesse 1 Robinson wrote:
>(Now with some actual content.) The standard justification for spin loop is
>that the area of code in question is executed *very* frequently and is *very*
>short.
>
I'd say, rather, the typical *wait* is *very* short.
>... In other
(Now with some actual content.) The standard justification for spin loop is
that the area of code in question is executed *very* frequently and is *very*
short. In other words, not worth the overhead of an actual WAIT nor the delay
in having to get redispatched afterwards. Spin loop is not an
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Tony Harminc
Sent: Monday, October
On Sun, 20 Oct 2019 at 02:32, David Crayford wrote:
> The only code I've seen that implements yield are synchronization
> routines. Consider a spin-lock which is spinning on a CS instruction.
Why would any application program on z/OS implement and use a spin
lock? Why do the authors of such
Back in the days of IPS/ICS dispatching control, wasn't there something
that was referred to as the 'wheeler-dealer mechanism' & does it still
exist in some form in the WLM code?
>From memory:
1. New task gets created and is assigned a time-slice of 1msec, at a
priority of 32 (out of 64 - i.e
I just looked up "External Interruption" in the Principles. There are at least
9 possible causes.
IIRC on the System 360 there was an eight-pin Molex connector available and a
customer-provided box of some sort could trigger an external interrupt by
pulling the appropriate pin to ground. See
On 2019-10-18 11:20 PM, Seymour J Metz wrote:
ObUnclean Does Unix System Services implement its own spin locks or does it use
MVS services? Does any *ix have spin locks outside of the kernel
Unclean is subjective ;)
pthread_spin_lock() - not implemented on z/OS
On 2019-10-19 14:45, Charles Mills wrote:
Others have given you good replies. I've been thinking about your question
and thought I would summarize and re-phrase what has been said. You are not
very specific in what your situation is, so let me offer three possible
problem scenarios, each with
Maybe the OP just wants to implement sched_yield() for the Dignus
compiler runtime?
On 2019-10-20 12:46 AM, Charles Mills wrote:
Thanks!
I suppose some encryption algorithm for which there was no hardware assist
available might be a more practical real-world scenario.
An encryption
Interesting, thanks! So it generates an external interrupt. I always
thought that one was only for the external interrupt "key", but this
page indicates CPU timer and some kind of CP-to-CP communication too:
Check out "CPU Timer" in the Principles of Operation.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Saturday, October 19, 2019 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to
Thanks!
I suppose some encryption algorithm for which there was no hardware assist
available might be a more practical real-world scenario.
> Is there something in the dispatcher that is on a timer that ends up saying
> this task has gotten enough CPU and it's time to move to the next TCB?
In
Great descriptions! I was thinking of the PI calculation myself because
that's a case where you're doing real work, but the loop could be coded
with no I/O and no SVC calls (which would give up control). Now here's
a case I thought about in the past: Assuming I'm running such a PI
On Sat, 19 Oct 2019 10:45:39 -0400, Charles Mills wrote:
>Others have given you good replies. I've been thinking about your question
>and thought I would summarize and re-phrase what has been said. You are not
>very specific in what your situation is, so let me offer three possible
>problem
Others have given you good replies. I've been thinking about your question
and thought I would summarize and re-phrase what has been said. You are not
very specific in what your situation is, so let me offer three possible
problem scenarios, each with its own solution.
I. "I am doing something
You only get the CPU for a time slice, or until the next interrupt occurs,
which is very often. After each interrupt, the highest priority piece of work
is dispatched. If you are still at the top, you go next. If not, you wait
until you are at the top of the dispatch chain.
Chris Blaicher
From a design perspective it would seem that your task is done and waiting for
more work? Generally I’d think you’d want to wait and have someone post that
work is ready or an stimer to wait for a period of time.
z/OS is unlike many operating systems where it will pre-empt running work and
On Thu, 17 Oct 2019 at 08:54, Thomas David Rivers wrote:
> Does anyone happen to know the best way for a running task
> to give up running and let another task run?
> Sorta like "I'm done for the moment if something else would like to run".
This sounds so wrong right from the start. Or rather,
ObUnclean Does Unix System Services implement its own spin locks or does it use
MVS services? Does any *ix have spin locks outside of the kernel?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf
Typically, OS services like these and it's Unix equivalent sched_yield()
are used in spinlocks.
On 2019-10-18 1:20 AM, Mike Hochee wrote:
Yes exactly, that is part of what WLM is designed to do. In the real world most
shops use WLM service classes and velocity goals to control things like CPU
STIMER WAIT for a small amount of time;
I did this some years ago, when I wanted to show to some students how some
parallel running subtasks wrote their messages not sequentially, but mixed;
but, as it turned out, every subtask did its complete work in one step,
once started, because it never
On 10/17/2019 10:31 AM, Thomas David Rivers wrote:
Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED?
What about just a regular un-AUTH'd program?
CALLDISP does not require privileged execution unless you specify
BRANCH=YES. Unauthorized callers should specify BRANCH=NO.
--
On Thu, Oct 17, 2019 at 12:31 PM Thomas David Rivers
wrote:
> Don Poitras wrote:
>
> >CALLDISP
> >
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm
> >
> >
> >
> >
> Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED?
>
> What about just
When BRANCH=NO
Environmental factorRequirement
Minimum authorization: None.
Dispatchable unit mode: Task
Cross memory mode: PASN=HASN=SASN
AMODE: 24- or 31- or 64-bit
ASC mode: Primary
Interrupt status: Enabled for I/O and external interrupts
Locks: No locks held
Control
Don Poitras wrote:
CALLDISP
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm
Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED?
What about just a regular un-AUTH'd program?
- Dave R. -
p.s. *Thanks* for the pointer...
--
Yes exactly, that is part of what WLM is designed to do. In the real world most
shops use WLM service classes and velocity goals to control things like CPU
dispatching frequency. I'm sure there exist workloads which tend to defy the
controls available in WLM, but I suspect they are quite rare.
Why? If you are waiting for something then you should use system services,
e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something
then why not let the WLM handle what it's designed to handle?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers
wrote:
>Does anyone happen to know the best way for a running task
>to give up running and let another task run?
>
>But - this isn't "give up" as in ending the task, just giving up
>the CPU to allow another task to run and then returning
That's awesome Don!
So that's how to implement sched_yield()?
On 2019-10-17 10:02 PM, Don Poitras wrote:
CALLDISP
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm
In article <066301d584f2$b397cdc0$1ac76940$@mcn.org> you wrote:
#1, MVS manages that
"I'm done for the moment if something else would like to run"
That's not for the task to decide: the dispatcher, under control of WLM,
decides whether you get the CPU or will be removed from it to allow another
task to run. All based on WLM directions, which you can influence by selecting
a
On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers wrote:
>Does anyone happen to know the best way for a running task
>to give up running and let another task run?
>
>But - this isn't "give up" as in ending the task, just giving up
>the CPU to allow another task to run and then returning to
CALLDISP
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm
In article <066301d584f2$b397cdc0$1ac76940$@mcn.org> you wrote:
> #1, MVS manages that sort of thing with its wisdom, right? If it thought
> someone else should run, it would pre-empt you and
#1, MVS manages that sort of thing with its wisdom, right? If it thought
someone else should run, it would pre-empt you and give control to that
other task.
#2, any SVC (or PC?) type system service call will cause MVS to re-evaluate
who should be dispatched *I think*.
Charles
-Original
WLM: give the job a Serice Class with Importance=5 and a Velocity=1. It will be
thankful for each CPU second that is left unused by all other tasks in the
system.
Kees.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas
56 matches
Mail list logo
