Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
28 user(s) are online (21 user(s) are browsing Forums)

Members: 1
Guests: 27

samo79, more...

Support us!

Headlines

 
  Register To Post  

« 1 2 (3)
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@joerg

Quote:

it's the number of IExec->Forbid(), Disable() and SuperState() calls per second.


Do you remember how those were checked? It seems that those "top" source codes are for a different binary version.

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@Capehill
I don't remember how I did it, but it's probably simply using IExec->SetMethod() to functions increasing a counter and calling the original functions.

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@joerg

Okay, I noticed that starting multiple top instances and quitting could get into trouble :)

Anyway, I'm stealing task switches / s and forbid % stats from your program...

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
I don't know why you are using own StringLen() and CopyString() functions instead of C library strlen() and str[nc]cpy() functions, but if you want to use own implementations don't use such extremely slow versions.
For example check the newlib sources for an unoptimised and very slow (no CPU specific code like AltiVec used), but still much better than what you are doing, version of strlen(): https://github.com/eblot/newlib/blob/m ... wlib/libc/string/strlen.c
A little bit better PPC assembler version (no AltiVec, data cache touch, streaming, etc., support code either): http://cvsweb.netbsd.org/bsdweb.cgi/s ... type=text/x-cvsweb-markup


Edited by joerg on 2023/5/21 3:02:40
Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@joerg

Probably because I needed to call these between Disable/Enable and I wasn't sure if the C lib versions were safe to call. I can just replace those with strlen and strncpy.

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@Capehill
There is too much Disable()/Enable() usage in your code anyway, most of it can be removed or replaced by atomic accesses.
But simple Newlib C library functions like strlen() and strlcpy() (the usually better replacement for strncpy()), which don't do any I/O and are reentrant code, can even be used in interrupt code and inside Disable()/Enable().
An exception to that might be functions like memcpy()/memmove(), but only for very large copies. On some systems they may be implemented using DMA, which needs to wait for the DMA operation to be completed and that might even be an IExec->Wait().

A tool like top/tequila should display CPU usage of other tasks, not cause much additional CPU usage, especially if it's without a reason like in this case

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@joerg

I'm calling Disable() twice to read task lists. Do you mean Forbid() is enough? Here they use Disable() https://wiki.amigaos.net/wiki/Exec_Tasks

I suppose it would be possible to copy task name also during timer interrupt, based on the assumption that task lists are consistent during interrupt.

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@Capehill
The tasklist.c example code in the wiki is completely broken, it's using IExec->AllocVecTags() without AVT_Wait,FALSE and AVT_NoExpunge,TRUE inside Disable()!
Allocating memory may require swapping out other memory and in this case the current task is suspended until that's done, which of course breaks Forbid() and Disable() states. Forbid() and Disable() states may be cancelled as well if memory handlers have to be called to free memory with the default AVT_NoExpunge,FALSE.

Why do you need task lists at all if you copy the task data, incl. the name, in the interrupt handler?

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@joerg

Yeah, well it was a surprise to me that it's even possible to allocate memory inside Disable. Not sure why anybody wanted to.

In addition to task data, I want to display total number of existing tasks.

Go to top
Re: Task scheduler
Just popping in
Just popping in


See User information
Quote:
joerg wrote:

tasklist.c example code in the wiki is completely broken, it's using IExec->AllocVecTags() without AVT_Wait,FALSE and AVT_NoExpunge,TRUE inside Disable()!


Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state?

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@Capehill
Quote:
Yeah, well it was a surprise to me that it's even possible to allocate memory inside Disable. Not sure why anybody wanted to.
You can call any functions inside Forbid() or Disable(), even IExec->Wait() or IDOS->Delay(), but using such functions will of course cancel the Forbid and/or Disable state ...

@Georg
Quote:
Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state?
No.

Go to top
Re: Task scheduler
Just popping in
Just popping in


See User information
@joergQuote:


@Georg
Quote:
Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state?
No.


Why not. Note that I said "auto-change *defaults*". AllocVecTags() caller would still be able to override it. I know there are times/cases where one intenionally and correctly (not bug) wants to (or even has to) go into forbid/disabled state and then calls something which breaks that foribd/disabled state.

Go to top
Re: Task scheduler
Just can't stay away
Just can't stay away


See User information
@Georg
Can't get into details because of NDA, but the AmigaOS 4.x ExecSG memory system doesn't have anything in common with the AmigaOS <= 3.y one at all.
Old/obsolete functions like AllocMem()/AllocVec()/etc. don't exist any more, they are all just stubs calling AllocVecTags().
Allocating memory doesn't only need a single memory allocator like it used to be in AmigaOS <= 3.x, but two different and independent ones: Before any virtual memory allocation can be done first physical pages have to be allocated by the page allocator for it, and that's done using different algorithms and access methods (atomic check+increase PPC instructions, and mutexes).


Edited by joerg on 2023/5/25 20:08:07
Go to top

  Register To Post
« 1 2 (3)

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project