home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.arch      Apparently more than just beeps & boops      131,241 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 129,541 of 131,241   
   Stephen Fuld to Stephen Fuld   
   Re: What I did on my summer vacation   
   30 Aug 25 08:16:04   
   
   From: sfuld@alumni.cmu.edu.invalid   
      
   On 8/29/2025 11:22 PM, Stephen Fuld wrote:   
   > On 8/29/2025 12:31 PM, MitchAlsup wrote:   
   >>   
   >> Stephen Fuld  posted:   
   >>   
   >>> On 8/29/2025 8:26 AM, MitchAlsup wrote:   
   >>>>   
   >>>> Stephen Fuld  posted:   
   >>>>   
   >>>>> On 8/21/2025 1:49 PM, MitchAlsup wrote:   
   >>>>>>   
   >>>>>> Greetings everyone !   
   >>>>>   
   >>>>> snip   
   >>>>>   
   >>>>>> My 66000 ISA is in "pretty good shape" having almost no changes over   
   >>>>>> the last 6 months, with only specification clarifications. So it   
   >>>>>> was time   
   >>>>>> to work on the non-ISA parts.   
   >>>>>   
   >>>>> You mention two non-ISA parts that you have been working on.  I   
   >>>>> thought   
   >>>>> I would ask you for your thoughts on another non-ISA part.  Timers and   
   >>>>> clocks.  Doing a "clean slate" ISA frees you from being compatible   
   >>>>> with   
   >>>>> lots of old features that might have been the right thing to do back   
   >>>>> then, but aren't now.   
   >>>>>   
   >>>>> So, how many clocks/timers should a system have?   
   >>>>   
   >>>> Lots. Every major resource should have its own clock as part of its   
   >>>> performance counter set.   
   >>>>   
   >>>> Every interruptible resource should have its own timer which is   
   >>>> programmed   
   >>>> to throw interrupts to one thing or another.   
   >>>   
   >>> So if I want to keep track of how much CPU time a task has accumulated,   
   >>> someone has to save the value of the CPU clock when the task gets   
   >>> interrupted or switched out.  Is this done by the HW or by code in the   
   >>> task switcher?   
   >>   
   >> Task switcher.   
   >>   
   >>>                  Later, when the task gets control of the   
   CPU again,   
   >>> there needs to be a mechanism to resume adding time to its saved value.   
   >>> How is this done?   
   >>   
   >> One reads the old performance counters:   
   >>      LDM   Rd,Rd+7,[MMIO+R29]   
   >> and saves with Thread:   
   >>      STM   Rd,Rd+7,[Thread+128]   
   >>   
   >> Side Note: LDM and STM are ATOMIC wrt the 8 doublewords loaded/stored.   
   >>   
   >> To put them back:   
   >>      LDM   Rd,Rd+7,[Thread+128]   
   >>      STM   Rd,Rd+7,[MMIO+R29]   
   >   
   > I think there is a problem with that.  lets say there are two OSs   
   > running under a hypervisor.  And I want to collect CPU time for an   
   > application running under one of those OSs.  Now consider a timer   
   > interrupt to the hypervisor that causes it to switch out the OS that our   
   > program is running under and switch in the other OS.  The mechanism you   
   > described takes care of getting the correct CPU time for the OS that is   
   > switched out, but I don't think it "switches out" the application   
   > program, so the application's CPU time is too high (it includes the time   
   > spent in the other OS).   
      
   I apologize for the self follow-up, but upon further thought, I believe   
   I got this backward.  The interrupt will cause the accumulated CPU time   
   for the application that is running to be saved correctly, but nothing   
   will touch the value for the OS, so it will continue accumulating time,   
   even though the CPU is running the hypervisor, or even the other OS.   
      
      
   > I don't know how other systems with hypervisors   
   > handle this situation.   
   --   
     - Stephen Fuld   
   (e-mail address disguised to prevent spam)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca