Hi,
As mentioned above, do you know any alternative to calling
ExAllocatePoolWithTag when IRQL > DISPATCH_LEVEL ?
Thanks in advance.
Best regards.
Matth
What do you need to allocate?
Interesting question.
Suppose that some thread allocates memory with some system defined routine and that thread has just acquired a system defined lock (spin lock) at DISPATCH_LEVEL. Then, because it has a higher IRQL, your code preempts this thread, before it has released the lock. Your code then tries to acquire that same lock by calling the same system routine. The processor would be locked.
That’s why the DISPATCH_LEVEL IRQL is a limit. To me, the answer is no.
PS: The OS uses spin locks when memory is allocated or freed.
> As mentioned above, do you know any alternative to calling ExAllocatePoolWithTag when IRQL
DISPATCH_LEVEL ?
I think Abdel gave you a very reasonable explanation of why doing something like that is unsafe by its very definition. I would add that any code that wants to allocate memory or access system dispatcher at IRQL>DISPATCH_LEVEL is simply “broken by design” - you have to redesign it so that your “requirement” gets eliminated…
Anton Bassov
On 2016-05-10 18:19:01 +0000, xxxxx@broadcom.com said:
Hi !
What do you need to allocate?
I need to allocate a buffer to copy audio data into and then schedule a
DPC to process the audio data buffer each time IDMAChannel::CopyTo is
called.
I should allocate a buffer once and reuse this buffer instead of
allocating it again and again.
I don’t want to use a circular buffer to avoid the problem of buffers
overlapping each other, even though a circular buffer could be a good
solution.
On 2016-05-10 23:11:37 +0000, xxxxx@gmail.com said:
Hi !
Interesting question.
Suppose that some thread allocates memory with some system defined
routine and that thread has just acquired a system defined lock (spin
lock) at DISPATCH_LEVEL. Then, because it has a higher IRQL, your code
preempts this thread, before it has released the lock. Your code then
tries to acquire that same lock by calling the same system routine. The
processor would be locked.
Thanks for the explanation !
That’s why the DISPATCH_LEVEL IRQL is a limit. To me, the answer is no.
Ok.
PS: The OS uses spin locks when memory is allocated or freed.
On 2016-05-11 00:34:08 +0000, xxxxx@hotmail.com said:
Hi !
>
> As mentioned above, do you know any alternative to calling
> ExAllocatePoolWithTag when IRQL
> DISPATCH_LEVEL ?I think Abdel gave you a very reasonable explanation of why doing
something like that is unsafe by its very definition. I would add that
any code that wants to allocate memory or access system dispatcher at
IRQL>DISPATCH_LEVEL is simply “broken by design” - you have to redesign
it so that your “requirement” gets eliminated…
I now understand why it is not possible.
I definitely have to make some changes about the design of the project
I am working on, memory management is one of the most important part of
such changes.
Anton Bassov
Hmmmm… odd statement, that second one, about “buffers overlapping each other” – If a buffer is not big enough, it doesn’t matter if you start filling it from offset zero or at the offset you last stopped writing. It’s STILL not big enough. It’s just a matter of mechanics, the code you write, and getting that right.
Peter
OSR
@OSRDrivers
On 2016-05-11 11:39:17 +0000, xxxxx@osr.com said:
Hi,
Hmmmm… odd statement, that second one, about “buffers overlapping
each other” – If a buffer is not big enough, it doesn’t matter if you
start filling it from offset zero or at the offset you last stopped
writing. It’s STILL not big enough. It’s just a matter of mechanics,
the code you write, and getting that right.
I totally agree about what you said, my statement is not correct and
incomplete, sorry about that.
The circular buffer mechanism is not a problem which leads to buffer
overlapping, it’s a bug in the implementation which does and it can be
fixed easily.
The real problem is not being able to estimate the circular buffer size.
I’m trying to find a solution to dynamically allocate buffers instead
of statically but I hav to face the problem of how could I call
ExAllocatePoolWithTag when IRQL > DISPATCH_LEVEL.
Peter
OSR
@OSRDrivers
Right. That’s not possible. Do some design and write some code to avoid thus “requirement”…
Peter
OSR
@OSRDrivers
On 2016-05-11 14:10:06 +0000, xxxxx@osr.com said:
Right. That’s not possible. Do some design and write some code to avoid
thus “requirement”…Peter
OSR
@OSRDrivers
Ok
I suspect that you are trying to optimize something that is not necessary on most machines. Some basic math about the data rate you expect and probably latency of consumers will give you a good estimate of the required circular buffer size and adding in a reasonable ?factor of safety? will probably give you a size in the small ones of megabits ? a large sounding size that is mostly irrelevant for modern machines; remember that even desktop CPUs have L1 caches of this size now
If I am wrong, please feel free to tell me all about it and expound further on your real problem.
Sent from Mailhttps: for Windows 10
From: Matthieu Collettemailto:xxxxx
Sent: May 11, 2016 8:57 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re:[ntdev] Any alternative to calling ExAllocatePoolWithTag when IRQL > DISPATCH_LEVEL ?
On 2016-05-11 11:39:17 +0000, xxxxx@osr.com said:
Hi,
>
>
> Hmmmm… odd statement, that second one, about “buffers overlapping
> each other” – If a buffer is not big enough, it doesn’t matter if you
> start filling it from offset zero or at the offset you last stopped
> writing. It’s STILL not big enough. It’s just a matter of mechanics,
> the code you write, and getting that right.
I totally agree about what you said, my statement is not correct and
incomplete, sorry about that.
The circular buffer mechanism is not a problem which leads to buffer
overlapping, it’s a bug in the implementation which does and it can be
fixed easily.
The real problem is not being able to estimate the circular buffer size.
I’m trying to find a solution to dynamically allocate buffers instead
of statically but I hav to face the problem of how could I call
ExAllocatePoolWithTag when IRQL > DISPATCH_LEVEL.
>
> Peter
> OSR
> @OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
Hi !
On 2016-05-11 23:18:13 +0000, Marion Bond said:
I suspect that you are trying to optimize something that is not
necessary on most machines. Some basic math about the data rate you
expect and probably latency of consumers will give you a good estimate
of the required circular buffer size and adding in a reasonable ‘factor
of safety’ will probably give you a size in the small ones of megabits
– a large sounding size that is mostly irrelevant for modern machines;
remember that even desktop CPUs have L1 caches of this size now
More than trying to optimize, I am trying to anticipate problem that
will probably never occur.
Taking into accout a circular buffer size twice as big as the maximum
remote playback buffer will be enough.
Speaking of problem, what if the computer goes in energy saving mode,
what will be the impact on my driver ?
If I am wrong, please feel free to tell me all about it and expound
further on your real problem.
Â
Sent from Mail for Windows 10
Â
From: Matthieu Collette
Sent: May 11, 2016 8:57 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Any alternative to calling ExAllocatePoolWithTag
when IRQL > DISPATCH_LEVEL ?
Â
On 2016-05-11 11:39:17 +0000, xxxxx@osr.com said:Hi,
> [quote]
> I should allocate a buffer once and reuse this buffer instead of
> allocating it again and again.
> I don’t want to use a circular buffer to avoid the problem of buffers
> overlapping each other, even though a circular buffer could be a good
> solution
> [/quote]
>
> Hmmmm… odd statement, that second one, about “buffers overlapping
> each other” – If a buffer is not big enough, it doesn’t matter if you
> start filling it from offset zero or at the offset you last stopped
> writing. It’s STILL not big enough. It’s just a matter of mechanics,
> the code you write, and getting that right.
I totally agree about what you said, my statement is not correct and
incomplete, sorry about that.The circular buffer mechanism is not a problem which leads to buffer
overlapping, it’s a bug in the implementation which does and it can be
fixed easily.The real problem is not being able to estimate the circular buffer size.
I’m trying to find a solution to dynamically allocate buffers instead
of statically but I hav to face the problem of how could I call
ExAllocatePoolWithTag when IRQL > DISPATCH_LEVEL.>
> Peter
> OSR
> @OSRDrivers
NTDEV is sponsored by OSR
Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:>