C. C. Bakshi

dblp:14/1937 · DBLP profile ↗
← Back
1ranked-venue papers
1as first author
0since 2021 · last 1992
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Applied, interdisciplinary, general and emerging computing · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
1 paper
Memory systems · 50% Embedded and real-time systems · 25% Cloud and datacenter computing · 25%
Software engineering, system software, and programming languages
1 paper
Operating systems · 100%

Topics — the 5 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Cloud and datacenter computing › resource management
memory resource management
0.011992
A virtual memory system for real-time applications · RTSS 1992
Embedded and real-time systems
real-time operating systems
0.011992
A virtual memory system for real-time applications · RTSS 1992
Memory systems › memory management
virtual memory
0.011992
A virtual memory system for real-time applications · RTSS 1992
Memory systems
virtual memory management
0.011992
A virtual memory system for real-time applications · RTSS 1992
Operating systems › resource management
memory management
0.011992
A virtual memory system for real-time applications · RTSS 1992

Methods — techniques the papers use, named apart from their topics

performance tuning · 0.0Unix-like API design · 0.0
YearPublicationVenuePosition
1992 A virtual memory system for real-time applications
abstract
A virtual memory implementation for a real-time environment is presented. The authors considered the special needs of real-time clients and provided a programmable mechanism for clients to control their memory resource needs and constraints. As a design goal they wanted the API to be as simple as possible. They made it look similar to the Unix interface so that client programs could be ported easily from Unix to the target environment. The authors viewed the implementation as risky from the onset and as a result planned on various mechanisms to tune the system. They also planned on extensive performance tools for the same reason. They have seen benefits in the potential flexibility due to this implementation. The authors describe the client interface, implementation details, performance results from the initial implementation, and recent efficiency improvements.>
C. C. Bakshi, L. Bela
RTSS1